Mehrfache Telegramme auf den Bus mit KNX Anbindung

[erru]

Hallo,
ich benutze momentan die Revision 1223.
Der Server läuft in der eclipse Umgebung.
Ich habe in *.items nur einen Switch definiert.
Sobald ich diesen Switch schalte, bekomme ich 3 Telegramme auf den Bus geschrieben. Dies passiert beim Ein- als auch beim Ausschalten.
Als Schnittstelle habe ich knx:ip=224.0.23.12 und knx:type=ROUTER angegeben.
Ist das normal, dass bei jedem Event 3 Telegramme verschickt werden?

Wenn ich die Anbindung auf knx:type=TUNNEL stelle, schreibt er mir ununterbrochen den Bus mit Telegrammen voll.

Habt ihr das auch?

Ach so. Ich benutze übrigens den eibd in Version 0.0.4 da er in Version 0.0.5 nicht mehr mit der ETS 3 funktioniert.

Gruß
erru

[teichsta]

kannst Du sehen welche drei Telegramm das sind? Wenn nicht dann bitte mit start_debug.xxx starten ...

[erru]

Hallo teichsta,
ich habe mal ein Screenshot angehängt.
Die ersten 6 Telegramme sind vom Einschalten, dahinter folgt dann das Ausschalten.

Und dann noch aus der Console:
17:22:46.246 INFO runtime.busevents[:42] - Light_Office received command ON
17:22:46.246 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'ON' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
17:22:46.247 INFO runtime.busevents[:46] - Light_Office state updated to ON
17:22:46.248 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'ON' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
17:22:46.253 INFO runtime.busevents[:42] - Light_Office received command ON
17:22:46.253 INFO runtime.busevents[:46] - Light_Office state updated to ON
17:22:46.254 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'ON' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
17:22:46.491 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2
17:22:48.704 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2
17:22:51.418 INFO runtime.busevents[:42] - Light_Office received command OFF
17:22:51.419 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'OFF' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
17:22:51.420 INFO runtime.busevents[:46] - Light_Office state updated to OFF
17:22:51.420 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'OFF' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
17:22:51.426 INFO runtime.busevents[:42] - Light_Office received command OFF
17:22:51.426 INFO runtime.busevents[:46] - Light_Office state updated to OFF
17:22:51.426 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'OFF' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
17:22:51.665 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2
17:22:53.902 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2

[teichsta]

hmm ... kannst Du mir gerade nochmal die Konfiguration des Items aus der .items "zeigen"?

[erru]

OK, hier ist es.

Inhalt von demo.items:

Group All
Group gGF (All)

Switch Light_Office "Büro" (gGF) {knx="2/0/0"}


Inhalt von demo.sitemap

sitemap demo label="Main Menu"
{
Frame {
Group item=gGF label="Ground Floor" icon="groundfloor"
}
}

[teichsta]

die Ursache für das Verhalten ist eine Änderung, für ich noch einen Review machen muss (siehe: Issue 95 - openhab - Code review request - empowering the smart home - Google Project Hosting)

Als Workaround ändere bitte die Item-Config wie folgt:

Switch Light_Office "Büro" (gGF) { knx="2/0/0", autoupdate="false" }

möglicherweise braucht man auch folgendes:

Switch Light_Office	"Büro" (gGF) { knx="2/0/0+2/0/0", autoupdate="false" }

da bin ich jetzt nicht ganz sicher, weil ich den Code gerade nicht vor Augen habe.

[erru]

Guten Morgen teichsta,
habe beide Varianten ausprobiert. Leider führt keine zum Erfolg, da sich das Licht dann nicht wieder ausschalten lässt. Es wird aber jetzt immerhin nur ein Telegramm auf den Bus gesendet.

Hier die Console mit Switch Light_Office "Büro" (gGF) { knx="2/0/0", autoupdate="false" }

10:20:56.748 INFO runtime.busevents[:42] - Light_Office received command ON
10:20:56.749 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'ON' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
10:20:56.756 INFO runtime.busevents[:42] - Light_Office received command ON
10:20:56.822 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2
10:20:59.152 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2
10:21:05.679 INFO runtime.busevents[:42] - Light_Office received command ON

// HIER BEGINNT DER AUSZUG FÜR DAS OFF KOMMANDO
10:21:05.680 DEBUG o.o.b.k.i.bus.KNXBinding[:172] - Wrote value 'ON' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
10:21:05.687 INFO runtime.busevents[:42] - Light_Office received command ON
10:21:08.196 DEBUG o.o.b.k.i.bus.KNXBinding[:244] - Received telegram for unknown group address 2/0/2

Hast du evtl. noch eine Idee?


Ich habe mir den Code mal angeschaut.
Mir ist aufgefallen, dass in der folgenden Methode auch ein writeToKNX erfolgt.
Das wird auch in der Methode internalReceiveCommand(String itemName, Command command) ausgeführt.
Wenn ich das writeToKNX in internalReceiveUpdate auskommentiere, funktioniert es. Allerdings kann ich die Seiteneffekte nicht einschätzen.

@Override
protected void internalReceiveUpdate(String itemName, State newState) {
logger.trace("Received update (item='{}', state='{}')", itemName, newState.toString());
if (!isEcho(itemName, newState)) {
writeToKNX(itemName, newState);
}
}



Was meinst du dazu?

[kkreuzer]

Hallo erru,

wie teichsta anmerkte, haben wir im 1.0.0-SNAPSHOT gerade einen Bug eingeführt, den wir bis zum Release nächste Woche noch geradeziehen müssen. Evtl. reicht Dein Vorschlag mit dem writeToKNX(), müssen wir uns näher anschauen.

Von Deinen Logs sieht es so aus, als schickst Du auf 2/0/2 den Status Deines Aktors - insofern solltest Du in *.items auf alle Fälle folgendes schreiben:

{ knx="2/0/0+2/0/2", autoupdate="false" }

Dann bekommst Du auch gleich die Status-Updates richtig in openHAB mit.

Grüße,
Kai

[erru]

Hallo Kai,
vielen Dank für deine Antwort.
Leider funktioniert es bei mir mit deinem Rat nicht so wie gewünscht.

Wieso hat das Problem sonst keiner?
Was benutzt du für eine Anbindung?

Gruß
erru

[kkreuzer]

Wieso hat das Problem sonst keiner?

Vermutlich, weil es erst mit einem Commit letzte Woche eingeführt wurde - ich benutze noch eine etwas ältere Version als Produktivsystem und habe daher diese Probleme wohl noch nicht gemerkt. Das ist immer das Risiko, wenn man ein SNAPSHOT Release einsetzt :-)

Wie teichsta oben schon angemerkt hat, wird er die nächsten Tage noch diese Änderung reviewen - er hatte von ähnlichem Verhalten wie von Dir beobachtet berichtet. Gibt uns also einfach ein paar Tage Zeit, dann sollte es behoben sein; spätestens zum 1.0 Release in einer Woche!

Kannst Du zwischenzeitlich vielleicht einfach mal das 0.9.1 Release ausprobieren? Da sollte bei KNX alles so funktionieren, wie erwartet.

Grüße,
Kai

[erru]

Hallo Kai,

Release 0.9.1 funktioniert in Bezug auf das thematisierte Problem einwandfrei.

Gruß
erru

[kkreuzer]

Ich habe gestern eine Änderung gepusht - bei mir verhält sich nun alles, wie gewünscht (jedenfalls nach ersten Tests).
Könntest Du bitte auch nochmal die 1.0.0 gegentesten?

Danke!
Kai

[erru]

Hallo Kai.
Habe die aktuelle Version mal getestet.
Die doppelten Telegramme werden jetzt nicht mehr gesendet. Super.

Allerdings bin ich jetzt auf ein anderes Problem gestoßen.
Es werden intern zwei Events für ein Kommando erzeugt.
Anbei ein Auszug:


20:10:46.364 DEBUG o.o.m.r.i.engine.RuleEngine[:310] - Executing rule 'Timer Demo'
20:10:46.365 INFO runtime.busevents[:42] - Light_Office received command ON
20:10:46.367 DEBUG o.o.b.k.i.bus.KNXBinding[:177] - Wrote value 'ON' to datapoint 'command DP 2/0/0 Light_Office, DPT main 0 id 1.001, low priority'
CREATE TIMER NO NULL
20:10:46.370 DEBUG o.o.m.s.a.ScriptExecution[:121] - Scheduled code for execution at 2012-08-15T20:10:56.368+02:00
20:10:46.378 DEBUG o.o.m.r.i.engine.RuleEngine[:310] - Executing rule 'Timer Demo'
20:10:46.379 INFO runtime.busevents[:42] - Light_Office received command ON

Dadurch wird auch eine vorhandene Regel 2 mal ausgeführt.
Das hat zur Folge, dass ein Retrigger nicht möglich ist, da beim zweiten Aufruf
der Regel der Timer Triggerkey von dem zweiten Aufruf nicht mehr da ist.
Das würde nur gehen, wenn man die aufzurufenden Skripte im selben Thread abarbeiten würde.
Also in RuleEngine.java in der Methode
protected synchronized void executeRule(Rule rule, RuleEvaluationContext context)

Soll ich für dieses Problem einen weiteren Thread eröffnen?

Gruß
erru

[kkreuzer]

Hi,

danke fürs Testen, ich schaue es mir mal an. Nicht nötig, ein neues Thema zu eröffnen.

Grüße,
Kai

[kkreuzer]

Ich habe gerade einige meiner letzten Änderungen reverted - mir waren diese so kurz vorm Release nun einfach zu riskant.
Als Ergebnis sollte sich die 1.0.0 bei KNX-Updates genauso verhalten wie die 0.9.1. Der neueste Build ist bereits auf diesem Stand.

Falls es noch Probleme gibt - einfach melden :-)

Grüße,
Kai