ARDUINO am KNX

[wintermute]

Wenn du mir sagst, welchen Code du nun genau auf dem Arduino hast (im Repository auf Bitbucket sind ja nur einige Teilfunktionen), schreibe ich mal was. Debuggen überlasse ich dir - da müssen wir dann halt vermutlich ein paar Runden drehen.

Hi Max,

schau mal in dem Example-Ordner nach dem LearnKNXAddress.ino und dort nach der Funktion serialEvent1. Nach kurzem Ueberfliegen wuerde ich vermuten, dass da schon fast alles drinsteckt was du brauchst.
Wenn das laeuft bau ichs zukuenftig in meine Beispielsketche ein - versprochen

gruesse

[wintermute]

So ich hab die BCU bestellt, aber kennt Ihr das schon?
Prototype PCBs of the Arduino TPUART Interface | Daniel's Blog
Das Ding ist doch in SMD wirklich klein zu bekommen - ich versuch am Wochende mal meine Eagle Kenntnisse zu vertiefen und schau mal was der Bauteil-Spaß kostet.

Ja, den Chip kenn ich. Problem fuer mich (und vermutlich fuer viele andere auch ) wird sein, dass man das einfach nicht geloetet bekommt...

Aber wenn du das wirklich klein machen willst:
Schau dir doch mal auf arduino.cc die Schaltplaene an. Was einen normalen Atmel von dem Arduino unterscheidet ist schlussendlich dann bloss der Bootloader. Wenn Du das beides dann auf eine Platine bekommst die man zB in eine groessere DIP Fassung stecken kann koennte ich mir vorstellen, dass einige Leute da Interesse dran haetten. Ich zB

gruesse

[JuMi2006]

Gestern ist mein Mega gekommen und ich war echt verblüfft wie einfach Arduino ist. Nach 10 Minuten funktionierte "blink" ... wir hatten Besuch und volles Haus also blieb Abends nur nochmal ne halbe Stunde. Die hat aber gereicht um einen 1-Wire DS18B20 und einen iButton auszulesen. Auf dem Steckbrett war die "Schaltung" in 2 Minuten fertig.
Ich muss dann wohl doch mal die Siemens-BCU bestellen .

EDIT:
So ich hab die BCU bestellt, aber kennt Ihr das schon?
http://dka.web-republic.de/2013/04/p...art-interface/

Das Ding ist doch in SMD wirklich klein zu bekommen - ich versuch am Wochende mal meine Eagle Kenntnisse zu vertiefen und schau mal was der Bauteil-Spaß kostet.

[l0wside]

Hallo Thorsten,

danke fürs Angebot, aber ich habe hier ausreichend Baustellen. Der KNX-Multisensor nähert sich endlich der v1.0. Und eine BCU wäre bei mir nachher einfach übrig.

Wenn du mir sagst, welchen Code du nun genau auf dem Arduino hast (im Repository auf Bitbucket sind ja nur einige Teilfunktionen), schreibe ich mal was. Debuggen überlasse ich dir - da müssen wir dann halt vermutlich ein paar Runden drehen.

Max

[ThorstenGehrig]

Ist das jetzt eigentlich bei dir schon im Wirkbetrieb ???
Bist du mit deinem ekey nicht mehr zu Frieden ??

Ja - Wirkbetrieb seit dem Wochenende zu vollster Zufriedenheit :-)
Ich habe ja "schon immer" einen 125kHz RFID-Leser - bisher von RSS per RS485 an Wiregate. Diese Anbindung war aber nicht immer 100%ig - das neue Projekt ist jezt viel Besser.
Den eKey habe ich erst später nachgerüstet - und nutze nun beide, je nach geschmack. Beim "normalen Heimkommen" habe ich den Autoschlüssel eh in der Hand und das öffnen geht schneller per RFID. Beim Spazieren oder Fahradpahren nehme ich den Finger - die Kinder auch. Mieter im Haus sind eher RFID Nutzer und ein wenig skeptisch dem eKey gegenüber (die Frau nutzt sogar meistens den richtigen Schlüssel.

Für mich ist dieses Projekt ein voller Erfolg :-D

Ein kurzer Blick in die DKA-Lib zeigt das Beispiel "ReceiveKNXTelegrams" - ich nehme an, das habt ihr verwendet?

Dort wird

KnxTelegram* telegram = knx.getReceivedTelegram();

aufgerufen, die eigentliche Verarbeitung steht nicht drin.

Für die Verarbeitung eines PropertyWrite braucht es nicht viel:
...

Hi Max,
Einen (großen/Mega) Arduino kann ich dir gerne zur Verfügung stellen - hab gerade einen Übrig. Du bräuchtest nur eine Siemens BCU?
Meine Kentnisse von C sind wirklich nur rudimentär - und ich bin Stolz das ich es soweit zum Laufen gebracht habe. Wenn du die PropertyWrite-Thematik einbauen willst: sehr gerne.
Wintermute ist da noch ein bisschen "im Code drinnen" - aber Zeitlich wohl sehr eingeschränkt...

Gruß
Thorsten

[l0wside]

Hi Max,

ich bin da prinzipiell voll und ganz bei Dir und halte die Idee sowas in einen quasi-Standard zu giessen fuer eine ganz tolle Idee. Aaaaber...

An der Arduino-Lib macht der urspruengliche Entwickler scheinbar nix mehr, daher hat Thorsten ja auch einen eigenen Fork davon auf die Beine gestellt. An dem haben bisher (AFAIK) nur Thorsten und ich kleinere Sachen gebastelt, die sich im wesentlichen auf bisher nicht implementierte DPTs (die wir fuer unsere Basteleien brauchten) und einige kleine Bugfixe beschraenkt.

Hallo Michael,

deinen Punkt kann ich voll und ganz verstehen. Ich halte den Aufwand aber für überschaubar. Ein kurzer Blick in die DKA-Lib zeigt das Beispiel "ReceiveKNXTelegrams" - ich nehme an, das habt ihr verwendet?

Dort wird

KnxTelegram* telegram = knx.getReceivedTelegram();

aufgerufen, die eigentliche Verarbeitung steht nicht drin.

Für die Verarbeitung eines PropertyWrite braucht es nicht viel:

• Prüfen, ob das empfangene Paket physikalisch an den entsprechenden Knoten adressiert ist
• Octets 6 und 7 prüfen. PropertyValueRead ist 1 1 1 1 / 0 1 0 1 0 1 (untere 4 Bit von Octet 6 und Bits 8-3 von Octet 7). PropertyWrite ist 1 1 1 1 / 0 1 0 1 1 1. PropertyValueResponse ist 1 1 1 1 / 0 1 0 1 1 0. Den Rest von Octet 6 und 7 kann man für diesen Zweck getrost ignorieren. In DKA ist das mit KNX_COMMAND_ESCAPE kodiert, man muss also nur Octet 7 auswerten.
• Der Rest des Aufbaus ist einheitlich für alle drei zugehörigen Befehle:
  • Octet 8: Object ID
  • Octet 9: Property ID
  • Octet 10, Bits 8-5: Anzahl Elemente
  • Octet 10, Bits 4-1 und Octet 11: Start Index
  • Ab Octet 12 dann Nutzdaten
  
  

Ich hatte das im Stack an einem Abend implementiert. Ist doch nur ein bisschen Bitschubserei. Ich habe keinen Arduino, sonst würde ich euch das notfalls abnehmen. Aber bitte, bitte keine Separatlösungen wie Linux mit KDE und Gnome.
Vorschlag: wenn ihr PropertyWrite verwendet, kümmere ich mich die nächsten Tage um passende Skripte auf Linux-Seite.

xpropwrite local:/tmp/eib 7.0.5 1 0 0 1 3E 00

ist zugegebenermaßen nicht eben intuitiv (setzt bei meinen Sensoren das Sendeintervall auf 60 Sekunden).


Max

[wintermute]

die PA (Geräteadresse) ist eher Statisch und imho reicht es das im Code zu definieren

Ich habs nicht ausprobiert, aber zumindest theoretisch koennte man einen Programmiertaster dazu bauen (hab ich jetzt bei meiner Platinenbestellung natuerlich nicht bedacht :/ ) oder einfach einen DI auf 5V legen. Die KNX-Lib muesste das eigentlich hergeben, dann koennte man zumindest die PA normgerecht einprogrammieren.
Schau ich mir die Tage mal an...

gruesse

[JuMi2006]

Ich finde beide Projekte äusserst interessant und es werden sich sicherlich Synergien ergeben.

Beide haben unterschiedliche Zielgruppen und vielleicht lässt sich ja auf dem Arduino beides zur Programmierung verwenden?

Ich sehe eher den Arduino als einfache Grundlage für die Entwicklung "echter" Geräte ... also: Weitermachen !

[keldan2]

Hi
hier mal eine kleine Projektdokumentation zu meinem RFID-Leser-Projekt.

Gruß
Thorsten

Ist das jetzt eigentlich bei dir schon im Wirkbetrieb ???
Bist du mit deinem ekey nicht mehr zu Frieden ??

LG und Danke
Daniel

[ThorstenGehrig]

Hi,
@dreamy: ja - mitbestellen eines VOCs wird gerne genommen.
Ich habe jetzt zwar weniger an eine Komplettlösung mit Display gedacht (das Projekt wird sicherlich größer als "nur" den VOC auszulesen und per Telegramm zu schicken... - aber ich bin da offen).
DC-DC Wandler sind auch schon auf dem Weg zu mir - wobei ich mir nicht sicher bin ob es noch im Rahmen ist soviel Strom aus dem Bus abzugreifen... Alternativ muss halte ne seperate SV her - so wie bei meinem RFID Leser.

Zur Programmier-Logik: die PA (Geräteadresse) ist eher Statisch und imho reicht es das im Code zu definieren. GAs ändert man auch eher nicht... was man ändert sind Parameter.
Parameter kann man ja gerne & einfach per GA setzen (und im Arduino im EEPROM speichern) - das macht ja Wintermute auch in seinem Beispiels-Sketch.

Gruß
Thorsten

[dreamy1]

Da muss ich Michael zustimmen. Die meisten hier werden eine Lösung wollen, die ohne jegliche Programmier- und Softwarekentnisse funktioniert und auch Platz für eigene Erweiterungen bietet.
Sicher ist der MSP mitsamt KNX-Stack eine geniale Lösung und ich finde das Projekt wirklich superklasse, aber da muss man sich wohl richtig einarbeiten um halbwegs zu verstehen was da abgeht :-)

Ich überblicke da aber im Moment auch nicht alles was die MSP-Seite angeht. Wenn ich es richtig verstanden habe, bräuchte man bei Deiner Version irgendein Tool auf PC Seite, welches die Parametrierung übernimmt. Das heißt, es ist ein Tool und auf jeden Fall eine IP-Schnittstelle notwendig...da finde ich es ehrlich gesagt eleganter, alles mit "Bordmitteln" der ETS lösen zu können. Zumal man da ja auch nicht ständig ändert, i.d.R. spielt man da am Anfang etwas rum bis alles passt und dann lässt man das Teil arbeiten und in Ruhe. Und eine GA mit der ETS schreiben kann jeder.

Am Ende soll alles so einfach wie möglich sein, sowohl soft- als auch hardwaremäßig. Bei der Hardware achte ich sogar darauf, alles möglichst in nicht-SMD zu layouten. So kann das Projekt jeder, der halbwegs mit einem Lötkolben umgehen kann, nachbauen.

[wintermute]

Es wäre m.E. sehr hilfreich, wenn wir uns auf diese Variante für die DIY-Projekte einigen könnten. Die Implementierung im Stack ist auch kein großer Aufwand.

Hi Max,

ich bin da prinzipiell voll und ganz bei Dir und halte die Idee sowas in einen quasi-Standard zu giessen fuer eine ganz tolle Idee. Aaaaber...

An der Arduino-Lib macht der urspruengliche Entwickler scheinbar nix mehr, daher hat Thorsten ja auch einen eigenen Fork davon auf die Beine gestellt. An dem haben bisher (AFAIK) nur Thorsten und ich kleinere Sachen gebastelt, die sich im wesentlichen auf bisher nicht implementierte DPTs (die wir fuer unsere Basteleien brauchten) und einige kleine Bugfixe beschraenkt. Zumindest mir fehlt die Zeit und auch die Motivation mich erstmal mit der Grundlagenimplementierung zu befassen, wenn es nur um kleinere Bastelprojekte geht - ich will in erster Linie was Funktionierendes haben damit ich endlich meine fehlenden Sockelleisten davor kleben kann
Wie das an der Stelle mit Thorsten aussieht kann ich natuerlich nicht sagen.
Aber ohne mehr Leute die ihre Haende in der hier verwendeten KNX-Lib haben, sehe ich da nicht so viel Erfolgschancen, ehrlich gesagt.

Das waere dann aber auch nur die Implementierung im uC bzw der Lib. Dann fehlt noch die Definition der XMLs (bzw DTDs) fuer die "Konfigurations-Clients" und plattformuebergreifende Client-Versionen, zB mal fuer Windows und Linux - Mac waere auch nicht schlecht, zumindest ich koennte das gut brauchen.
Nach Moeglichkeit auch welche, die sich einfach entpacken und starten lassen - denn nicht alle die hier mitlesen moechten/koennen/wollen sich derart tief in die Materie einarbeiten. Wenn das nicht entsprechend simpel wird ist es auch nicht pflegeleicht - wenn ich nach 2 Monaten nicht mehr weiss mit welchen haendischen Befehlsabfolgen auf welcher Plattform und mit Little/Big Endian Kodierung ich jetzt eigentlich so genau welches Ziel erreichen kann ist das zwar ein schoener Gedanke, aber kaum zu benutzen. Ein Blick in den Source verraet mir im Gegenzug sofort welche GA ich ueber die ETS schreiben muss um das gewuenschte Ergebnis zu bekommen - sogar im Klartext.

Versteh mich bitte nicht flasch: die Idee ist ganz toll und unterstuetzenswert, aber bis das rund und brauchbar im Raum steht - vor allem so, dass jeder hier damit zufrieden ist - ist Weihnachten.
Und dann muss es auch wirklich zukunftssicher sein - denn der Hauptvorteil waere ja die nicht mehr notwendige Umprogrammierung des uC.

Ich lass mich aber gern jederzeit eines besseren belehren!

PS: ich hab hier zB einen ABB Aktor bei dem ich die Dauer des Treppenlichtes ueber eine GA aendern kann. Das ist doch eigentlich nicht so unterschiedlich von der Konfiguration einer Frequenz zum zyklischen Senden. Scheinbar ist das also garnicht so unueblich GAs fuer sowas zu benutzen, oder?

gruesse :: Michael

[l0wside]

Mir sprudeln gerade mal wieder so die Ideen raus...aber ohne fremde (Programmier-)Hilfe wird das bei mir nichts...:

Mit der Möglichkeit, dass der Arduino gleichzeitig GA schreiben&lesen kann, eröffnen sich ja ganz neue Möglichkeiten:

Wie wäre es mit einer Parametrierung via ETS-Gruppenmonitor? Ich stelle mir das so vor:

Ich hatte hier: https://knx-user-forum.de/372418-post40.html schon einen Vorschlag gemacht, der PropertyRead/Write nutzt. Das entspricht dem Standard eher als die gewaltsame Verwendung einer GA (du willst ja ein Gerät konfigurieren, da ist die PA die passende Adressierung).

Es wäre m.E. sehr hilfreich, wenn wir uns auf diese Variante für die DIY-Projekte einigen könnten. Die Implementierung im Stack ist auch kein großer Aufwand.

Gruß,

Max

[wintermute]

Alternativ wäre auch eine einzige Parametrier-GA mit EIS15 denkbar...man müsste den gesendeten String dann im Arduino entsprechend "zerlegen". So könnte man dann einfach mit einem "ZyklT=200" den neuen Zykluswert setzen.

Das ist eine brillante Idee!
Ich warte zZ noch auf Platinen fuer die VirtualWall/1wire Sache die ich neulich gepostet habe. Wenn die da sind werde ich mich weiter mit dem Sketch befassen und das mal entsprechend verbauen - passt da sehr gut rein!

gruesse :: Michael

[dreamy1]

Mir sprudeln gerade mal wieder so die Ideen raus...aber ohne fremde (Programmier-)Hilfe wird das bei mir nichts...:

Mit der Möglichkeit, dass der Arduino gleichzeitig GA schreiben&lesen kann, eröffnen sich ja ganz neue Möglichkeiten:

Wie wäre es mit einer Parametrierung via ETS-Gruppenmonitor? Ich stelle mir das so vor:

Der Arduino wird initial mit einer PA geflasht und eingebaut. Die PA sowie Parametrierdaten werden im EEPROM gespeichert und beim Start in die Variablen gelesen. Nun werden in der ETS einige Dummy-GA's angelegt (für EIS6), wie z.B. im Falle eines Multisensors für Temperatur, Luftfeuchte und VOC:
x.x.1: PA-Hauptgruppe
x.x.2: PA-Mittelgruppe
x.x.3: PA-Untergruppe
x.x.4: Zykluszeit in sec. T
x.x.5: Zykluszeit in sec. H
x.x.6: Zykluszeit in sec. VOC
x.x.7: Kalibrierdelta T (deltaT=0,1*hinterlegter Wert)
...

Mit solchen Kommunikations-GA's könnte man dann per Gruppenmonitor in der ETS einfach eine neue PA "programmieren" oder z.B. die Zykluszeit ändern, mit der der aktuell gemessene Feuchtigkeitswert auf den Bus gesendet wird. Und das, ohne dass das Modul ausgebaut und neu geflasht werden muss :-)

Wär das nix?


Alternativ wäre auch eine einzige Parametrier-GA mit EIS15 denkbar...man müsste den gesendeten String dann im Arduino entsprechend "zerlegen". So könnte man dann einfach mit einem "ZyklT=200" den neuen Zykluswert setzen. Gefällt mir noch besser.

Ich sehe schon..das wird Arbeit :-)