Plugins auslagern - eBus/KNX Daemon

[XueSheng]

Kann man mit knxd eigentlich auch die cycle Befehle des ebusd verwerten? Oder ist das Ganze auf set/get Befehle beschränkt?

[JuMi2006]

AW: Plugins auslagern - eBus/KNX Daemon

Ja. Die cycle werden intern wie ein get verarbeitet.

Baustelle 2.0

[Gast]

hi,

ist zwar etwas Offtopic paßt aber gerade dazu.

Der ebusd hält stets die letzte Nachricht für jedes als zyklischen definierte Telegramm vor.
Ein cyc Klasse Befehl Unterbefehl bekommt somit diese Daten zugestellt.

cu

[XueSheng]

D.h., dass cycle Befehle durch knxd sofort auf den Bus geschrieben werden, wenn diese durch ebusd ausgelesen worden sind? Oder arbeitet knxd mit einer festen Zykluszeit?

Wenn ich über eine Gruppenadresse eine Leseanfrage sende und bei knxd-ebusd.csv ein cycle Befehl hinterlegt ist, kann es dann passieren, dass der Rückgabewert veraltet ist?

(Ich weiss, dass hierüber schon in dem Ursprungsthread diskutiert worden ist, aber mir ist unklar, wie nun die tatsächliche Umsetzung aussieht)

[JuMi2006]

Ja in dem Falle kann es sein dass die Daten nicht aktuell sind.
Ein Response ist (noch) nicht implementiert.

Beim set/get ist es schon etwas schlauer.
Setze ich einen Wert via "set" wird in der knxd-ebusd.csv nach einem gleichnamigen "get" gesucht und dieses auch abgefragt.

Beispiel aus der Praxis:

8/6/100 = get cir2 mode
8/7/100 = set cir2 mode

Sende ich nun einen Wert auf die 8/7/100 so wird direkt danach auch auf die 8/6/100 der aktuelle Wert gesendet. In der Visu ist damit dann die 8/7/100 eine beschreibbare Adresse und 8/6/100 readonly. So hat man gleich die Kontrolle ob der Befehl erfolgreich ausgeführt wurde. Das Abfragen eines Befehles dauert i.d.R. 0,3-0,6 Sekunden.

Grundsätzlich arbeitet der knxd bzw. das Plugin mit einer festen Zykluszeit. Diese teilt es durch die aktuelle Anzahl vorhandener get/cycle Befehle. Bei mir sind momentan 180 Sekunden eingestellt und es werden knapp unter 30 Werte abgefragt. Also alle 6 Sekunden bekommt der ebusd den Auftrag ein Telegramm zu senden. Die Werte auf dem Bus sind damit also auch immer maximal 180 Sekunden alt, nach einem "set" natürlich brandaktuell.

Am Response habe ich schon gesessen und werde es sicherlich auch noch implementieren.

[JuMi2006]

Also ich hab gestern Abend mal das Response implementiert.
Funktioniert ganz gut. Gleichzeit hat der knxd noch eine neue Funktion bekommen.

In den Plugins kann man jetzt

$plugin_subscribe
$plugin_subscribe_read
$plugin_subscribe_write

benutzen

• $plugin_subscribe - abonniert das Plugin auf jede Art von Telegrammen
• $plugin_subscribe_read - abonniert das Plugin nur bei Read-Telegrammen
• $plugin_subscribe_write - abonniert das Plugin nur bei Write-Telegrammen

Ich versuche da zum Wochenende mal ein sauberes Package zu erstellen und die Source-Files zu aktualisieren.

[XueSheng]

Zum Teil Offtopic, aber falls Makki mitliest...
Wäre die Aufsplittung für $plugin_subscribe nicht auch was für die Standard Plugins des Wiregate?

Bislang filtere ich read/write/response bei jedem Pluginaufruf. Da muss man sich tatsächlich fragen, ob es Sinn macht, das vorab zentral zu filtern. Von der Reaktionsgeschwindigkeit her wird es vermutlich keinen wirklichen Unterschied machen, aber man könnte Plugins gezielter aufrufen.

Könnte man nicht bei $plugin_subscribe, die übergebene Variable als "flag" interpretieren, um read/write/response zu unterscheiden.
Anstatt 0 bzw. 1 würde man unterscheiden:
read = 1, write = 2, response = 4; read/write wäre folglich 3; write/response wäre 6; default wäre 7 (alles). Quasi in Anlehnung an die Rechtevergabe in Linux.

Wenn man $plugin_subscribe als Variable behalten will und die Abwärstkompatibilität in Betracht zieht, müsste man natürlich einen anderen Zahlenbereich wählen. 0/1 würde seine Gültigkeit behalten und 2/4/8 kämen dazu... wie auch immer, nur ein Denkanstoß.

[JuMi2006]

AW: Plugins auslagern - eBus/KNX Daemon

Ich hatte eh vor das makki in einem separaten Thread vorzuschlagen.

Die jetzige (meine) Implementierung finde ich allerdings sinniger und macht bestehende Plugins ja auch nicht kaputt. Liegt aber auch darin dass ich kein Fan Flags bin und der Code ohne Zusatzinfos verständlich ist.

Edit: Da $plugin_subscribe ein Hash ist müsste man bei einem zusätzlichen Parameter ziemlich viel im Code wühlen.

Baustelle 2.0

[XueSheng]

Wie kann man eigentlich prüfen, ob ein set Befehl, der über eine Gruppenadresse ausgelöst wurde, auch von knxd wahrgenommen worden ist?
Nachdem nun die WW Speicherladung meiner Geotherm auch über ebusd (telnet) angestoßen werden kann, wollte ich dies nun auch über knxd einbinden.

knxd-ebusd.csv enthält folgenden Eintrag:

11/3/149;1;;;set;short hw_load;Quick - WW Speicherladung

knxd habe ich natürlich auch neugestartet, nachdem der Eintrag hinzukam.
Wenn ich eine '1' auf die Gruppenadresse 11/3/149 schicke, passiert jedoch nichts. Wie kann ich prüfen, ob knxd überhaupt das Telegramm wahrgenommen hat?

[JuMi2006]

Den knxd musst Du nicht neustarten. Die config wird bei jedem Durchlauf geprüft.

Was allerdings wichtig ist: Die GA sollte in /etc/knxd/eibga.conf eingetragen sein, alternativ einen Symlink auf die /etc/wiregate/eibga.conf herstellen, dann hat man nur eine eibga.conf zu pflegen.

Im laufenden Betrieb kannst Du das log mit folgendem Befehl über die Konsole beobachten:

tail -f /var/log/knxd-plugin.log

Da das ganze ein Trigger ist gibt es keine richtige Rückmeldung. Bei Fragen immer her damit, ich komme im Moment neben Garten, Familie und Beruf nicht dazu das alles zu fixen. So ganz glücklich bin ich mir der ganzen Lösung im Moment noch nicht da mir da zu viele Abhängigkeiten drin sind. Evtl. bekomme ich das Plugin noch so gelöst dass es keine eibga.conf braucht. ICh hab ja alles was ich brauche schon in der knxd-ebusd.csv. Sehe ich mir heute Abend mal an.

[XueSheng]

In der eibga.conf steht die GA noch nicht drin. Wollte mir den Aufwand zum Testen sparen.
Probier ich später mal aus!

Wenn GA und DPT schon in der csv stehen, warum wird eibga.conf überhaupt benötigt?

[JuMi2006]

Das ist genauso gelöst wie beim WireGate, ist ja auch nur ein abgespeckter wiregated.pl mit zusätzlichen kleine Features.

Ich hab mir den Code mal angesehen und eine Lösung dafür. Die eibga.conf ist eben ein zentrale Ort der Konfiguration, aber das bekomme ich in diesem Fall umschifft. Du kannst ja auch andere Plugins auf dem knxd laufen lassen.

[JuMi2006]

Ich kämpfe gerade mit meinem SVN-Client. Daher mal das Update hier.

knxd.pl --> /usr/sbin
ebusd.pl --> /etc/knxd/plugin

Damit wird nun ein "Read" vom Bus unterstützt und der Wert live ausgelesen. Die GA die angefragt wird muss mit "get" oder "cycle" in der knxd-ebusd.csv geführt sein.

Weiterin sind die unterschiedlichen Arten von $subscribe_plugin eingearbeitet.

Die eibga.conf ist damit für das ebus-Plugin überflüssig. Die DPTs werden jetzt aus der knxd-ebusd.csv ermittelt.

Bitte mal kurz Rückmeldung geben ob es klappt.

Grüße

[XueSheng]

Habe die Dateien kopiert und sicherheitshalber meine Verlinkung der eibga.conf gelöscht... Läuft!
Danke für die schnelle Hilfe!

[JuMi2006]

Wie lange läuft der knxd schon bei Dir? Mich würde mal interessieren wie sich der Speicherverbrauch entwickelt. Dafür müsste es ein RRD geben -> knxd_mem.rrd - es läuft doch bei Dir auf dem WireGate oder? Ich hab das bisher nur auf dem Pi am laufen.