ARDUINO am KNX

[kblankenheim]

Hallo zusammen,

klasse Projekt! Danke an alle die hier Zeit investiert und mitgeholfen haben!!

Bei mir funktioniert das alles wunderbar. Bei der Beobachtung es Busverkehrs bin ich jetzt allerdings auf ein Problem gestoßen. Die Arduinos scheinen zu versuchen untereinander Verbindung aufzunehmen, haben dabei keinen Erfolg und „verstopfen“ den Bus mit tausenden von Nachrichten. Das Verhalten tritt - bisher nicht reproduzierbar - nur zeitweise auf. Der Sketch auf den Arduinos ist ganz einfach nur einen Schalter abfragen.

Ich habe mal über Nacht -wenn sonst wenig Busverkehr ist - den Busverkehr mitgeschnitten und angehängt.

Hat jemand etwas ähnliches beobachtet?

LPDU: BC B1 01 11 07 60 E2 67 :L_Data low from 11.1.1 to 1.1.7 hops: 06 T_ACK Serno:08 
LPDU: BC B0 01 B1 01 60 E2 C0 :L_Data low from 11.0.1 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: BC BB 02 B1 01 60 E2 C8 :L_Data low from 11.11.2 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: 9C BB 02 B1 01 60 E2 E8 :L_Data (repeated) low from 11.11.2 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: 9C BB 02 B1 01 60 E2 E8 :L_Data (repeated) low from 11.11.2 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: 9C BB 02 B1 01 60 E2 E8 :L_Data (repeated) low from 11.11.2 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: BC B0 01 BB 02 60 E2 C9 :L_Data low from 11.0.1 to 11.11.2 hops: 06 T_ACK Serno:08 
LPDU: 9C B0 01 BB 02 60 E2 E9 :L_Data (repeated) low from 11.0.1 to 11.11.2 hops: 06 T_ACK Serno:08 
LPDU: 9C B0 01 BB 02 60 E2 E9 :L_Data (repeated) low from 11.0.1 to 11.11.2 hops: 06 T_ACK Serno:08 
LPDU: 9C B0 01 BB 02 60 E2 E9 :L_Data (repeated) low from 11.0.1 to 11.11.2 hops: 06 T_ACK Serno:08 
LPDU: BC B1 01 B0 01 60 E2 C0 :L_Data low from 11.1.1 to 11.0.1 hops: 06 T_ACK Serno:08 
LPDU: BC BB 02 B0 01 60 E2 C9 :L_Data low from 11.11.2 to 11.0.1 hops: 06 T_ACK Serno:08 
LPDU: 9C BB 02 B0 01 60 E2 E9 :L_Data (repeated) low from 11.11.2 to 11.0.1 hops: 06 T_ACK Serno:08 
LPDU: 9C BB 02 B0 01 60 E2 E9 :L_Data (repeated) low from 11.11.2 to 11.0.1 hops: 06 T_ACK Serno:08 
LPDU: 9C BB 02 B0 01 60 E2 E9 :L_Data (repeated) low from 11.11.2 to 11.0.1 hops: 06 T_ACK Serno:08 
LPDU: BC B0 01 B1 01 60 E2 C0 :L_Data low from 11.0.1 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: 9C B0 01 B1 01 60 E2 E0 :L_Data (repeated) low from 11.0.1 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: 9C B0 01 B1 01 60 E2 E0 :L_Data (repeated) low from 11.0.1 to 11.1.1 hops: 06 T_ACK Serno:08 
LPDU: 9C B0 01 B1 01 60 E2 E0 :L_Data (repeated) low from 11.0.1 to 11.1.1 hops: 06 T_ACK Serno:08

[Leonelf]

Hallo!
Wir haben noch ein paar Busch-Jaeger Buskoppler rumliegen, kann man diese auch nutzen, oder greift da die Hersteller(er)kennung?

[ThorstenGehrig]

Hi
@kblankenheim: was sendest du denn?
Gibt es für diese GA einen Empfänger "auf dem Bus" - oder nur im Rasperi?
Grund der Frage: wenn ein Telegramm nicht auf dem Bus von einem Teilnehmer empfangen wird - wird sie (laut SPezifikation) 3x wiederholt...
Ein normales IP Gateway (und auch EIBD) "ACK´en" (bestätigen) ein Telegramm normal NICHT (für den EIBD gibt es - zumindest für´s Wiregate - ein "ack-all"-parameter....)

Zur not einfach mal die genutzte Gruppenadresse auch auf einen Aktor legen - dann kommt auch ein ACK auf dem Bus an...

@Leonelf: die BCU ist kein BA - daher wird dein BJ-BA nicht funktionieren (auch wenn BCU und BA identisch aussehen... sind sie es nicht)

Gruß
Thorsten

[Andi99]

KNX Nachrichten Empfangen funktioniert nicht

Hallo,

leider schaffe ich es nicht, den Code von htwg/Pascal bzw. von Mag Gyver zum Laufen zu bringen.
Mein Vorgehen:
- Code z.B. von Mag Gyver in IDE kopieren
- physical address anpassen KnxTpUart knx(&Serial, "0.0.50")
- Pragramm auf Arduino UNO R3 übertagen
- USB entfernen
- Arduino an Busankoppler(Siemens 5WG1) anschließen
- GND an BUS-Pin1 (unten links)
- TX->1 an BUS-Pin2
- RX<-0 an BUS-Pin4
- 5V an BUS-Pin5
- Resetknopf drücken und ca. 20 Sekunden warten
- die Gruppenadresse 0.0.1 am Bus mit 1 auslösen
- jetzt sollte doch zumindest die LED 13 kurz aufblitzen

Was mach ich falsch?
Ich habe das Identische auch mit void serialEvent1() ohne Erfolg getestet.

Vielen Dank

Gruß
Andi
PS: Das Senden funktioniert perfekt!

[Mag Gyver]

Hallo Andi 99,

folgende Angaben beziehen sich auf meinen Sketch.

Die LED 13 blinkt beim Starten des Sketch nur kurze Zeit. Bei "Unknown Event" blitzt die LED 13 kurze Zeit.
Aber bei Gruppenadresse 0.0.1 wird Ausgang 11 angesteuert und bei Gruppenadresse 2.5.0 wird Ausgang 12 angesteuert.

Es laufen bei mir 6 Stück EIBuinos seit mehreren Monaten ohne Probleme (nur Senden).
Seitdem htwg/Pascal seinen Sketch eingestellt hat, laufen jetzt 2 Stück mit zusätzlich zum Senden auch noch Empfangen von Gruppenadressen.

Benütze bitte die Libary https://bitbucket.org/dka/arduino-tpuart/downloads und natürlich den 5WG1 117-2AB12 von Siemens.

Deine Hardwareanschlussbelegung stimmt -> Wackler ?

Bei USB-Speisung (Verbindung zum PC) musste ich den Pin 5 mit Pin 6 der ICSP1 mit einander kurzschließen.

Busankoppler zum Programmieren des EIBunios immer abstecken, ansonsten gibt es eine Fehlermeldung.


Grüße

Mag Gyver

[kblankenheim]

Achtung NCD Telegramme!

Die Methode KnxTpUart::readKNXTelegram() ruft immer sendNCDPosConfirm(...) auf wenn ein NCD Telegramm empfangen wurde und zwar unabhängig von der Zieladresse. Das ist nicht sinnvoll und kann einfach behoben werden.

Hier mal eine kurze Fehleranalyse. Arduino mit physikalischer Adresse 1.1.31 und dem folgendem Sketch:

#include <KnxTpUart.h>
#include <Bounce2.h>

KnxTpUart knx(&Serial1, "1.1.31");

String  SEND_GROUP_1     =  "3/0/5";     // DG Flur
String  LISTEN_GROUP_1   =  "3/0/5";     // DG Flur
int  LISTEN_GROUP_1_INT  =  6149;         // t_main*2048 + t_middle*256 + t_sub

bool    light_state      =  false;

#define BUTTON_PIN 9

// Instantiate a Bounce object
Bounce debouncer = Bounce(); 

void setup() {
  
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for Leonardo only
  }
  Serial.println("TP-UART Test");  

  Serial1.begin(19200);
  UCSR1C = UCSR1C | B00100000; // Even Parity

  knx.uartReset(); 
  knx.addListenGroupAddress(LISTEN_GROUP_1);  
  
  // setup the button and Bounce object
  pinMode(BUTTON_PIN, INPUT_PULLUP);  
  debouncer.attach(BUTTON_PIN);
  debouncer.interval(20);
}


void loop() {
  
  boolean stateChanged = debouncer.update();
  
  if (stateChanged) {  
      // the state has changed, send knx event
      light_state = !light_state;
      bool success = knx.groupWriteBool(SEND_GROUP_1, light_state);
  }
}

void serialEvent1() {
  // nur zum Testen ...
  KnxTpUartSerialEventType eType = knx.serialEvent();

}

Ich erzeuge aus der ETS ein paar NCD (Numbered Control Data) Pakete (Diagnostics → Individual Adresses… → List all existing addresses in a line) die via USB Datenschnittstelle (15.15.255) auf den Bus gelangen:

LPDU: B0 FF FF 11 01 61 43 00 7D :L_Data system from 15.15.255 to 1.1.1 hops: 06 T_DATA_CONNECTED_REQ serno:00 A_DeviceDescriptor_Read Type:00 
LPDU: B0 11 01 FF FF 60 C2 FD :L_Data system from 1.1.1 to 15.15.255 hops: 06 T_ACK Serno:00

Soweit so gut. Jetzt mal aufgepasst. Was ist dass?

LPDU: BC 11 1F 11 01 60 C2 FF :L_Data low from 1.1.31 to 1.1.1 hops: 06 T_ACK Serno:00

Der Arduino (1.1.31) schickt ein acknowledge an 1.1.1? Wofür? 1.1.1 hat ein NCD Paket an 15.15.255 geschickt. Da schauen wir mal genauer hin:

bool KnxTpUart::readKNXTelegram()
Source: 1.1.1
Target Physical: 15.15.255
Interested (group, physical, broadcast) = 0, 0, 0 	[B]<= wir sind nicht interessiert[/B]
NCD Telegram 0 received
NCD sending positive confirm >>>>>>	[B]<= und senden trotzdem eine acknowledge an 15.15.255 weil in KnxTpUart::readKNXTelegram() ein NCD Teleramm unabhängig von der Zieladresse immer bestätigt wird[/B]
NCD Waiting for confirmation >>>>>>	[B]<= und warten auf eine Antwort von 15.15.255 die wir nicht bekommen[/B]

Wenn wir jetzt nur einen Arduino haben, endet die NCD-Warteschleife irgendwann und dann ist bis zum nächsten NCD-Paket gut. Es können aber Pakete verloren gehen.

Jetzt nehmen wir mal einen zweiten Arduino mit dem gleichen Sketch und physikalischer Adresse 1.1.34 dazu.

Der empfängt das NCD acknowledge das von 1.1.31 an 1.1.1 geschickt wurde :

LPDU: BC 11 1F 11 01 60 C2 FF :L_Data low from 1.1.31 to 1.1.1 hops: 06 T_ACK Serno:00

und schickt wie oben ein ACK an 1.1.31 (weil in KnxTpUart::readKNXTelegram() ein NCD Telegramm unabhängig von der Zieladresse immer bestätigt wird)

LPDU: BC 11 22 11 1F 60 C2 DC :L_Data low from 1.1.34 to 1.1.31 hops: 06 T_ACK Serno:00
LPDU: 9C 11 22 11 1F 60 C2 FC :L_Data (repeated) low from 1.1.34 to 1.1.31 hops: 06 T_ACK Serno:00 
LPDU: 9C 11 22 11 1F 60 C2 FC :L_Data (repeated) low from 1.1.34 to 1.1.31 hops: 06 T_ACK Serno:00 
LPDU: 9C 11 22 11 1F 60 C2 FC :L_Data (repeated) low from 1.1.34 to 1.1.31 hops: 06 T_ACK Serno:00

Die beiden Arduinos fangen an sich gegenseitig Telegramme zu schicken und das ganze schaukelt sich auf und erzeugt eine extrem hohe Buslast. Bei mir kam teilweise kein anderes Packet mehr durch. Je mehr Arduinos angeschossen sind umso größer die Buslast.

[wintermute]

Hier mal eine kurze Fehleranalyse. Arduino mit physikalischer Adresse 1.1.31 und dem folgendem Sketch...

Heyho, tausend dank fuer die Analyse!!

Kannst du entsprechende Aenderungen in der Lib einchecken?


gruesse :: Michael

[ThorstenGehrig]

Ja - hut ab und danke.
Der Fehler kommt schon aus der Ursprünglichen Lib - bisher wahrscheinlich nie aufgefallen da die meisten nur einen Arduino im Programm haben.
Ich habe 2 permanent im Einsatz - und bisher keine Buslast-Steigerung gesehen... aber ich lese auch keine Telegramme vom Bus (ich sende nur).

Hast du die Änderung schon entwickelt?

Gruß
Thorsten

[kblankenheim]

Änderungen in der bitbucket library

aber ich lese auch keine Telegramme vom Bus (ich sende nur).

Richtig, dann hast Du das Problem nicht. Nur wenn man mit mehr als einem Arduino auch Telegramme empfängt.

Hast du die Änderung schon entwickelt?

Die kleine Anpassung an der Library findest Du hier Pull Request #1. Habe Issue #1 auf "Resolved" gesetzt.
Damit läuft es bei mir jetzt auch mit vier lesenden Arduinos seid mehreren Tagen stabil.

[ThorstenGehrig]

Perfekt.
Danke nochmals!

Die Library ist bereits aktualisiert...

Darf ich noch Fragen wofür die es Einsetzt? Ich bin immer Interessiert an referenprojekten :-)

Gruß
Thorsten

[kblankenheim]

wofür Du es Einsetzt

Klar. Als Raumsensoren im Berker Sensoreinsatz:

Luftfeuchete/Temperatur SHT11 I2C
Helligkeit TSL2561D I2C
VCO iaq-core I2C

[Mag Gyver]

Hallo Thorsten,

wäre es möglich auch die Zeit vom EIB/KNX zu bekommen?

Leider komme ich nicht dahinter, wie ich das anstellen sollte.
Meine Kenntnisse hierzu sind nicht ausreichend.




Grüße

Mag Gyver

[ThorstenGehrig]

Klar. Als Raumsensoren im Berker Sensoreinsatz:

Luftfeuchete/Temperatur SHT11 I2C
Helligkeit TSL2561D I2C
VCO iaq-core I2C

Oh - hört sich interessant an - vor allem mit dem iaq.
Kannst du die Schaltung und die Beschaffungsquellen (und Erfahrungen) hier veröffentlichen?

wäre es möglich auch die Zeit vom EIB/KNX zu bekommen?

Klar - wenn Du sie auf den Bus auch sendest. Ich habe gerade nicht die komplette Lib im Kopf - aber laut readme habe ich wohl "nur"
groupWriteTime("1/2/3", Day, Hours, Minutes, Seconds);
implementiert.
Ein einlesen der Uhrzeit sollte aber kein Hexenwerk sein. Wozu brauchst du die Zeit im Arduino?

Gruß
Thorsten

[Mag Gyver]

Jawohl sende ich die Zeit vom Zeitgeber (Theben) auf den Bus.

Würde die Zeit an ein weiteres System weitergeben, da es für dieses System keine direkte Schnittstelle zum EIB/KNX gibt.

Deshalb würde mir die Implementierung sehr weiterhelfen, nur leider stehe ich auf dem Schlau.

Grüße

Mag Gyver

[ThorstenGehrig]

Hi
ich vermute mal du brauchst nur die Zeit und nicht das datum?

Vorweg - mal wieder als Warnhinweiß: ich kann nicht Programmieren! (zumindest ist es 1000 jahre her).

So - also bisher sind in der KNX ja keine "groupRead..." funktionen implementiert - daher muss die Auswertung hier "händisch" erfolgen.

Beim "groupWriteTime" habe ich das Telegram so zusammengebaut (buffer ist das Tellegram, Nutzdaten ab byte[5]:

   // Day um 5 byte nach links verschieben
    day = day << 5;
    // Buffer[8] füllen: die ersten 3 Bits day, die nächsten 5 hour
    buffer[8] = (day & B11100000) + (hours & B00011111);

    // buffer[9] füllen: 2 bits leer dann 6 bits für minuten
    buffer[9] =  minutes & B00111111;
    
    // buffer[10] füllen: 2 bits leer dann 6 bits für sekunden
    buffer[10] = seconds & B00111111;

Das müssen wir nun umdrehen...
Zuerst natürlich immer der "außenrum-code" für das Lesen von Telegrammen:

knx.addListenGroupAddress("0/1/2");
  

void serialEvent() {  
    //Get Serial Event
    KnxTpUartSerialEventType eType = knx.serialEvent();
    //Check Serial Event
    if (eType == KNX_TELEGRAM) {
        KnxTelegram* telegram = knx.getReceivedTelegram();
        // Here you have the telegram and can do whatever you want
        ...
        ...
        ...

So - nun gehts an´s Telegram auswerten

	// Day is in the 3 first bits - so we have to extract (&B11100000) and move 5 bits to right
	day = (telegram[0] & B11100000) >> 5;
	
	// Hours is in the 5 next bits (B00011111)
	hour = (telegram[0] & B00011111);
	
	// Minutes is in the next byte (B00111111)
	minutes = (telegram[1] & B00111111);
	
	// Seconds are in the next byte (B00111111)
	seconds = (telegram[2] & B00111111);

Ich habe den code BLIND geschrieben (nicht vergessen: ich kann nicht wirklich Programmieren!).
Ich gehe mal davon aus das das "telegram" nur die Nutzlast enthält (daher [0][1] und [2], und nicht [8][9] und [10].
Ich gehe davon aus das der Code so nicht funktioniert...
Die Variablen (day,hour, minutes, seconds) müssen auch noch initialisiert werden...
Ich hoffe das dieser Ansatz dich zumindest auf den Lösungsweg schiebt.

Kommentare & Hilfe von "richtigen" Programmierern sind erwünscht - außerdem vielleicht auch Hilfestellung bei der implementierung von "groupRead..." Befehlen.

Gruß
Thorsten