ARDUINO am KNX

[Masifi]

Hallo Zusammen,

ich sehe das Ihr hier auch schon einiges geschafft habt. Ich arbeite auch mit KNX und Arduino.
Würde mich freuen wenn Ihr mal in meinen Forum-Eintrag vorbeischaut.

https://knx-user-forum.de/forum/%C3%...y-monitor-oder

Vielleicht ergeben sich daraus noch Synergien :-)

MFG Mat

[tuxedo]

Wow, schon 50 Seiten. Nun ja, auf zu den nächsten 50.

Und damit wir da bald hinzukommen, hier eine neue tolle Erkenntnis:

Ich hab ja schon in einem anderen Thread vom Espressif ESP8266 berichtet. Das Ding hat 4MB Speicher und viele Mhz "Rechenleistung" (hab von 80Mhz gelesen?).
Und da sich der ESP auch mit der Arduino IDE programmieren lässt, wäre es theoretisch möglich, den KnxStack mit dem ESP zu nutzen oder zur Not ohne viel Aufwand zu portieren.

Kleiner Vergleich AVR Arduino zu ESP8266:

	Arduino Micro	ESP8266, als "NodeMCU DevKit"
RAM	2.5k	32k + 80k (was die +80k bedeuten weiß ich noch nicht genau)
Flash	32k (davon 8k für den Bootloader)	4MB
Eeprom	1k	keinen, dafür aber 4MB benutzbaren Flash
CPU	16Mhz	80Mhz (??)
WLAN	nein	ja
Straßenpreis (günstigstenfalls)	ab 8..9EUR bei ebay, aliexpress: ähnlich	rund 8EUR bei ebay, über z.B. aliexpress für knapp 4EUR

Vielleicht traut sich ja jemand ran damit KNX auszuprobieren (komm grad selbst nicht dazu).

Hier noch ein paar Links:

http://www.voti.nl/blog/?p=52
http://neilkolban.com/tech/esp8266/
http://www.espressif.com
http://www.nodemcu.org

[Mag Gyver]

Hallo Bonscha,

dein Code funktioniert. Leider ist dieser etwas unvorteilhaft geschrieben. Hier mal ein Beispielcode für UNO:

#include <KnxTpUart.h>

KnxTpUart knx(&Serial, "1.1.199");
int LED = 13;
boolean target_15_0_0;


void setup() {

  pinMode(LED, OUTPUT); // Setting up status LED

  Serial.begin(19200);
  UCSR0C = UCSR0C | B00100000; // Even Parity

  knx.uartReset();

  knx.addListenGroupAddress("15/0/0");
}


void loop() {

}


void serialEvent() {
  //Get Serial Event
  KnxTpUartSerialEventType eType = knx.serialEvent();

  //Check Serial Event
  if (eType == KNX_TELEGRAM) {
    KnxTelegram* telegram = knx.getReceivedTelegram();

    // Telegrammauswertung auf KNX (bei Empfang immer notwendig)
    String target =
      String(0 + telegram->getTargetMainGroup())   + "/" +
      String(0 + telegram->getTargetMiddleGroup()) + "/" +
      String(0 + telegram->getTargetSubGroup());

    // Auswertung der Gruppenadresse des empfangenen Telegrammes und Zwischenspeicherung in Variable target
    if (telegram->getCommand() == KNX_COMMAND_WRITE) {
      // Auswertung des empfangenen KNX-Telegrammes mit Schreibbefehl (Flag) -> Aktion
      if (target == "15/0/0") {
        target_15_0_0 = telegram->getBool();
        if (target_15_0_0) {
          digitalWrite(LED, HIGH);
        }
        else {
          digitalWrite(LED,LOW);
        }
      }
    }
  }
}

Der Empfang funktioniert auch, auf dem UNO und MEGA.

DER GND TP-UART mit dem GND des Arduino zu verbinden (Ausnahme -> Optokoppler)

Beim UNO "void serialEvent()" sollte folgendes gemacht werden:

• (Nicht bei Erstprogrammierung, da gibt es keine Brücke zum entfernen) Die Brücke am (ICSP1 Pin 5 mit ICSP1 Pin 6) entfernen
• (Nicht bei Erstprogrammierung, nicht notwendig der ATmega 16u2 ist nicht im Programmiermodus) Den USB-Stecker ausstecken und wieder einstecken (Zwischen dem Ein- und Ausstecken ein bisschen Zeit vergehen lassen)
• Programmieren des UNO ohne angesteckten TP-UART (RxD,TxD).
• Nachdem Programmieren eine Brücke zwischen ICSP1 Pin 5 und ICSP1 Pin 6 herstellen
• Den TP-UART (RxD,TxD) (wieder)anschließen
• Resettaster am Arduino kurz drücken

Beim MEGA "void serialEvent1()" :

• Programmieren über USB "Serial"
• TP-UART (RxD,TxD) an "Serial1" anschliessen

Der NANO sollte eigentlich auch funktionieren, doch hier ist der Serial direkt an den FTDI angeschlossen.
Dies könnte mit hoher Wahrscheinlichkeit das Problem sein.
Keine Möglichkeit den FTDI abzuschalten, kann wahrscheinlich nur durch eine Hardwareeingriff gelöst werden.
Aber danach kann man den NANO nicht mehr per USB programmieren nur noch über ISP.


Mit freundlichen Grüßen

Mag Gyver

[Bonscha]

Hallo Mag Gyver, vielen Dank für deine Mühe. Ich habe endlich einen ATMega zum Testen und mache mich dann mal ran. Was müsste ich am Nano denn ändern, damit das läuft? Einfach die Pins vom FTDI, die an RxD und TxD gehen, trennen?

[Mag Gyver]

Hallo Bonscha,

muss mir das mit dem Nano erst genauer anschauen.
Habe nur einen flüchtigen Blick in den Schaltplan des NANO geworfen.
An der Hardware habe ich noch nichts getestet.

Trennen ist zu endgültig, dann sind ja die Vorteile der USB-Programmierung komplett weg.
Vielleicht ergibt sich ja eine bessere Alternative, das Datenblatt des FTDI wird vielleicht Auskunft geben.



Mit freundlichen Grüßen

Mag Gyver

[ThorstenGehrig]

Hi
hier auchnochmal für alle: meine KNX-Lib hatte die funktionen
groupWrite2ByteInt und groupAnswer2ByteInt nicht richtig implementiert (die groupAnswer2ByteFloat haben aber gepasst).
Ich habe die Lib gerade aktualisiert: https://bitbucket.org/thorstengehrig...forum/overview
Für die maintainer der Forks: bitte übernehmen (wenn nicht schon geschehen)

Gruß
Thorsten

[ThorstenGehrig]

Hi alle,
ich habe in meiner Library mal die ganzen examples angepasst.
Gerade für Empfangen von Telegrammen zum Schreiben (z.B. Aktor) oder Antworten auf KNX-Read-Requests.
Danke an Mag Gyver für das schöne Skelet - ich hab so einiges wiederverwendet :-)

Hier nochmal der Link für alle "Späteinsteiger": https://bitbucket.org/thorstengehrig...knx-user-forum

Ob jemand die Kardino-Lib aktualisiert (https://github.com/KNX-on-Arduino ) weiß ich nicht.
Übrigens: "blöder Name" - der wird schon mehrfach verwendet...
Ich bin da nicht dabei... (vielleicht kann mir ja mal jemand auf dem Stammtisch den Fork näherbringen).
Die groupWrite2ByteInt (und Answer)-Befehle sind da wohl noch kaputt.

Gruß
Thorsten

[tuxedo]

Ob jemand die Kardino-Lib aktualisiert (https://github.com/KNX-on-Arduino ) weiß ich nicht.
Übrigens: "blöder Name" - der wird schon mehrfach verwendet...
Ich bin da nicht dabei... (vielleicht kann mir ja mal jemand auf dem Stammtisch den Fork näherbringen).
Die groupWrite2ByteInt (und Answer)-Befehle sind da wohl noch kaputt.

Bin aktuell noch an was anderem dran. Darf sich aber gerne jemand dran austoben und einen Pull-Request machen.

Der Sinn und Zweck des Forks wurde hier schon mehrfach erwähnt:

"Große" Applikationen passen mit dem Ansatz "GA als String statt 2 byte" nicht sonderlich gut in den kleinen Speicher der AVRs. Strings sind da einfach zu verschwenderisch.
Und zum anderen wurde in dem Fork schon der Versuch unternommen memread/memwrite/propread/propwrite umzusetzen, was auch ansatzweise schon funktioniert.

Zum Namen: naja, irgendwas ist ja immer...

[ThorstenGehrig]

"GA als String statt 2 byte" hab ich verstanden - aber da gehe ich nicht mit.
Bisher habe ich kein Projekt gesehen was an die Grenzen kommt...

Das setzen KNX-Addresse per Button + LED Anzeige ist ja simple imzusetzen, macht ohne komplette parametrisierung (Gruppenaddressen) keinen Sinn.
Ein parametrisieren per ETS (oder selbstbautool) mit memread/memwrite/propread/wropwrite ist IMHO sehr ambitioniert - ich halte das eher notwendig für den Vertieb von fertigen Lösungen und weniger für den "DIY" bereich.
Die hinzukommende komplexität (sowohl von a als auch b) sehe ich die selbstbau-Zielgruppe weiter schrumpfen...
Für meinen Geschmack muss der Zugang so einfach wie möglich sein.

Um das zu Erreichen hat in meinen Augen das beste Potential eine Aufsteckplatine für den BCU mit integiertem Arduino - oder eine fertige Platine mit TP-UPART und Arduino.
Dazu eine "Library" an Beispielsprojekten (ich hab ja schonmal mit RFID-Leser, Regenmengenzähler und VOC-Sensor 3 Stück geliefert).

Weitere diskussionen dazu sollten wir Auslagern - und ein KNX-Stammtisch wäre sicherlich ein guter Ort ;-)
(heute in Kemmern/Frankenstammtisch?)

Gruß
Thorsten

[tuxedo]

"GA als String statt 2 byte" hab ich verstanden - aber da gehe ich nicht mit.

Musst du ja auch nicht.

Bisher habe ich kein Projekt gesehen was an die Grenzen kommt...

Wenn du einen 6-Kanaliges Gerät bastelst das pro Kanal rund 10 KOs hat und allgemein nochmal 10, dann bist du schon bei 70KOs.
Wenn alle 70 KOs eine rein 5-stellige String-GA haben (z.B. "1/2/3"), dann sind das schon mind. 350 bytes. Im Worst-Case wären es 560 bytes. Wenn man ein terminierendes 0-byte mit dazu rechnet ist es noch mehr.
Bei der 2byte-pro-GA Version sind es lediglich 140.

Das setzen KNX-Addresse per Button + LED Anzeige ist ja simple imzusetzen, macht ohne komplette parametrisierung (Gruppenaddressen) keinen Sinn.

Denke das will auch niemand wirklich so haben. Wenn dann alles, oder nichts.

Ein parametrisieren per ETS (oder selbstbautool) mit memread/memwrite/propread/wropwrite ist IMHO sehr ambitioniert - ich halte das eher notwendig für den Vertieb von fertigen Lösungen und weniger für den "DIY" bereich.

Einstellungssache. Für kleine Bastelprojekte mit 1-3 KOs muss man das nicht unbedingt haben. Aber wenn es mal mehr sind, und ein breites Publikum das DIY Gerät in AUgenschein nimmt, ist das sicher nicht verkehrt ein Tool zu haben.

Die hinzukommende komplexität (sowohl von a als auch b) sehe ich die selbstbau-Zielgruppe weiter schrumpfen...

Wie gesagt: Kleinst-Projekte sind da sicher anders. Wenn das Tool dazu kommt, dann ist es auch eine Frage der API. Die bisherige Basis "DKA KNX-TPUART" bietet da leider wenig gute voraussetzungen. Es gibt andere Umsetzungen die da strukturierter gearbeitet haben. Mehr dazu später...

Für meinen Geschmack muss der Zugang so einfach wie möglich sein.

Stimme ich dir voll zu.

Um das zu Erreichen hat in meinen Augen das beste Potential eine Aufsteckplatine für den BCU mit integiertem Arduino - oder eine fertige Platine mit TP-UPART und Arduino.

Hierzu gibt es bereits eine laufende Diskussion hier im DIY Bereich.

Weitere diskussionen dazu sollten wir Auslagern

Öhm *kopfkratz* Wurde doch schon getan, oder? Guckst du hier: https://knx-user-forum.de/forum/%C3%...ceiver-onboard

[Mag Gyver]

Hallo ThorstenGehrig,

dafür ist ja mein Beispiel da.

Kannst du noch etwas in deine Library aufnehmen?

Wenn ja, kann damit vom Arduino aus Leseanfragen auf eine Gruppenadresse abgegeben werden.

Änderungen:

In "Knx Tp Uart.h":

bool groupRead(String);

In "Knx Tp Uart.cpp":

bool KnxTpUart::groupRead(String Address) {
 createKNXMessageFrame(2, KNX_COMMAND_READ, Address, 0);
 _tg->createChecksum();
 return sendMessage();
}

Beispielcode:

#include <KnxTpUart.h>

KnxTpUart knx(&Serial, "1.1.199");

void setup() {
  Serial.begin(19200);
  UCSR0C = UCSR0C | B00100000;
  knx.uartReset();
}

void loop() {
   knx.groupRead("2/6/0");  // Zum Senden einer Leseanfrage vom Arduino zum KNX auf der Gruppenadresse "2/6/0"
}

void serialEvent() {
  KnxTpUartSerialEventType eType = knx.serialEvent();
}

Vielen Dank für deine Mühen.


Mit freundlichen Grüßen

Mag Gyver

[Mag Gyver]

Hallo Bonscha,

es gibt beim Arduino Nano nur zwei Möglichkeiten.

Erste Möglichkeit:

FTDI in den Reset zwingen (PIN19 des FTDI nach GND schalten), damit ist die Programmierung über USB abschaltbar und zuschaltbar.
Leider ist dies sehr knifflig wegen der Bauteilgröße.

Zweite Möglichkeit:

Trennen der Leiterbahnen zwischen FTDI und Arduino (RxD und TxD), damit ist die Programmierung über USB nicht mehr möglich.


In beiden Fällen geht danach aber das Senden und Empfangen von Befehlen zwischen Arduino Nano und KNX.


Mit freundlich Grüßen

Mag Gyver

[ThorstenGehrig]

Hi,
@Tuxedo: alles d´accord... aber hat ein Pro nicht 32kb - und sind dann die worst case 560byte immernoch "unkritisch"?
Zum Thema Austeckplatine habe ich noch eine andere - simplere- Idee... muss ich aber mal noch ausarbeiten.

mag Gyver: erledigt - allerdings habe ich die funktion umbenannt von groupRead auf groupReadBool.... wobei... ist der read-befehl so für alle Datentypen?
Dann muss ich das nochmal zurückändern.
Dein Beispiel fragt ja nur ab - bearbeitet aber nicht das ergebniss... vielleicht könntest du das Beispiel nochmal ergänzen?

Ürbigens müsstest du auf Bitbucket auch direkt arbeiten können... entweder als Fork und anschließenden Pull request - oder direkt im Editor.
(kann sein das ich doch dafür extra freischalten muss... wie ist dein Username?)

Gruß
Thorsten

[tuxedo]

Der Leonardo hat zwar 32k flash, aber 4 davon gehen für den Bootloader drauf. Bleiben noch 28k. Davon geht auch einiges für den Stack drauf. Hier geht's noch, hier kann man noch gut haushalten.

Die GAs liegen aber nicht im Flash, sondern im RAM. Und der ist nur 2,5k groß. Da sind 560byte schon rund 20%. Und da kanns dann wirklich eng werden.
Und ein Arduino sagt einem nicht "RAM voll", der fängt dann einfach an zu spinnen und sich "komisch" zu verhalten. Aber weniger im Sinne von witzig, sondern im Sinne von: "Was soll der scheiß, gerade eben ging's doch noch... und jetzt geht irgendwie gar nix mehr und ergibt auch keinen Sinn".

Man kann sie auch in den EEPROM auslagern und jedesmal bei bedarf einlesen. Kostet aber Zeit, die man bei zeitkritischen Anwendungen (und da gehört ein 6-kanal-dimmer eben dazu) nicht unbedingt verbraten will.

[Mag Gyver]

Hallo ThorstenGehrig,

ja die Funktion ist für alle Datentypen.

Beispiel:

/*
   Beispiel für Leseanfrage ARDUINO UNO -> KNX und Auswertung Antwort KNX -> ARDUINO UNO
  
   Version 0.2
  
   22.11.2015
  
   Testkonstellation = ARDUINO UNO <-> 5WG1 117-2AB12
*/


#include <KnxTpUart.h>

KnxTpUart knx(&Serial, "1.1.199");
int LED = 13;
int target_2_6_0;
int target_5_6_0;


void setup() {

  pinMode(LED, OUTPUT); // PIN 13 als Ausgang festlegen
 
  Serial.begin(19200);
  UCSR0C = UCSR0C | B00100000; // Gerade Parität

  knx.uartReset();
 
  knx.addListenGroupAddress("2/6/0");
  knx.addListenGroupAddress("5/6/0");
 
  // Leseanfrage auf Gruppenadresse -> alle Datentypen
 
  // Die Funktion delay(1000) nur zur Verzögerung der Initialisierungsabfrage notwendig.
  // Wenn man keine Initialisierungsabfrage möchte, sollte man die nächsten Zeilen bis Ende der Funktion aus kommentieren.
 
  delay(1000);
 
  // Leseanfrage auf Gruppenadressen -> Aufruf der Funktion Leseanfrage auch in void loop() möglich
 
  knx.groupRead("2/6/0");
  knx.groupRead("5/6/0");
}


void loop() {
  
}


void serialEvent() {
 
  //Aufruf knx.serialEvent()
 
  KnxTpUartSerialEventType eType = knx.serialEvent();

  //Auswertung des empfangenen Telegrammes -> nur KNX-Telegramme werden akzeptiert
 
  if (eType == KNX_TELEGRAM) {
    KnxTelegram* telegram = knx.getReceivedTelegram();

    // Telegrammauswertung auf KNX (bei Empfang immer notwendig)
  
    String target =
      String(0 + telegram->getTargetMainGroup())   + "/" +
      String(0 + telegram->getTargetMiddleGroup()) + "/" +
      String(0 + telegram->getTargetSubGroup());

    // Auswertung der Gruppenadresse des empfangenen Telegrammes und Zwischenspeicherung in Variable "target"
  
    if (telegram->getCommand() == KNX_COMMAND_ANSWER) {
    
      // Auswertung der Leseanfrage in serialEvent() mit Datentypen
      // Auswertung des empfangenen KNX-Telegrammes mit Antwort auf Leseanfrage (Flag) -> Aktion
    
      if (target == "2/6/0") {
        target_2_6_0 = telegram->getBool();
      
        // Speicherung des Inhaltes in Variable "target_2_6_0" der Antwort auf die Leseanfrage der Gruppenadresse "2/6/0"
      
        if (target_2_6_0) {
          digitalWrite(LED, HIGH);
        }
        else {
          digitalWrite(LED,LOW);
        }
      
        // Auswertung des Inhaltes und Ausgabe des Inhaltes der Gruppenadresse "2/6/0" auf PIN 13 des ARDUINO UNO
      }
      else if (target == "5/6/0") {
        target_5_6_0 = telegram->get1ByteIntValue();
      
        // Speicherung des Inhaltes in Variable "target_5_6_0" der Antwort auf die Leseanfrage der Gruppenadresse "5/6/0"
      
      }
    }
  }
}

Das mit Bitbucket muss ich mir erst anschauen.


Mit freundlichen Grüßen

Mag Gyver