ARDUINO am KNX

[wintermute]

der VOC ist nun mit drin :-)

Welchen Sensor benutzt du da eigentlich? Taet mich prinzipiell fuer mein Hauptabluftrohr interessieren.

gruesse :: Michael

[Monti]

Was die Leistungsentnahme angeht, da finde ich mehrerlei (teils widerspruechliche) Angaben in den Datenblaettern von Siemens:
1) 5V/10mA & 20V/25mA => 0.55W
2) 5V/50mA & 20V/0mA => 0.25W
3) 5V/30mA & 20V/25mA => 0.65W
4) 5V/0mA & 20V/25mA => 0.5W

Laut dem von Thorsten verlinkten Datenblatt sind die Möglichkeiten 2 und 3 die maximal zulässigen Werte. Die 5 V schwanken zwischen 4,75 V und 5,25 V. Die 20 V zwischen 17 V und 22,5 V. Wobei die untere Grenze bei maximaler Belastung noch um weitere 0,27 V absinken kann.

[dreamy1]

@Monti: das ist kein Problem, wenn man einen 3,3V-Arduino nimmt, auf der 20V-Seite wird ja eh nach 5V heruntergewandelt und das sind Eingangsspannungschwankungen kein Thema. Bei einem 5V-Arduino wäre ich auch vorsichtig, da bei Unterschreiten von 5V der LDO nicht mehr sauber ausregeln kann und jeder Ripple auch auf Sensoren an den AD-Eingängen durchschlägt, von Instabilitäten am Quarz ganz zu schweigen. Die Probleme hat man bei der 3,3V-Variante nicht, allerdings gibts die meist nur mit 8 MHz.

@Michael: Da habe ich mich noch nicht endgültig festgelegt. Entweder wirds ein AS-MLV (kaum beschaffbar), ein MICS-5526, ein MICS-5524 (sehr klein und energiesparend und billig, aber nur mit sehr hohen Versandkosten zu beschaffen) oder ein TGS-2602 (günstig und einfach beschaffbar) :-)
Favorit ist momentan letzterer, allerdings benötigt der den meisten Strom :-(

[ThorstenGehrig]

Hi
hier mal eine kleine Projektdokumentation zu meinem RFID-Leser-Projekt.
Der Arduino-Code ist noch der selbe wie früher - mit minimalen änderungen.
Derzeit sende ich die Seriennummer einfach an den HS zum Auswerten - das erspart umprogrammieren wenn ich einen neuen Transponer habe - und ermöglicht zusätzliche Sicherheits-Logiken (da RFID ja als unsicher anzusehen ist).
PA und Gruppenadresse muss natürlich im Code noch angepasst werden.

Gruß
Thorsten

[ThorstenGehrig]

Entweder wirds ein AS-MLV (kaum beschaffbar), ein MICS-5526, ein MICS-5524 (sehr klein und energiesparend und billig, aber nur mit sehr hohen Versandkosten zu beschaffen) oder ein TGS-2602 (günstig und einfach beschaffbar) :-)
Favorit ist momentan letzterer, allerdings benötigt der den meisten Strom :-(

Hi Dreamy,
hast du den VOC schon bestellt?
Ich würde vielleicht einen Mitbestellen? Oder einfach bei Conrad den TGS2602 für ~19€?
Ich denke die Anbindung an Arduino sieht einfach aus...
Kann man den VOC aus dem Wick Freshmatic ausbauen? Irgendwie hab ich da nichts konsistentes im Netz gefunden...

Gruß
Thorsten

[dreamy1]

Hallo Thorsten,

den VOC habe ich noch nicht bestellt, aber es wird wohl der TGS2600 oder TGS2602 werden. Ich bin gerade in Eagle dabei, das TO-5 Package entsprechend zu ändern damit der TGS mit seinen 4 Beinchen reinpasst.

Soll ich Dir mal einen mitbestellen?

Den Airwick-Sensor hatte ich schon im Auge, aber erstens scheint Airwick die Serie mit Geruchssensor aus dem Programm genommen zu haben und zweitens ist da sicher B- oder C-Ware eingebaut. Ich habe den nicht mehr weiter im Focus und die AS-MLV-Sensoren gibts nirgends zu kaufen.
Die MICS sind sehr schön, auch von Daten her, leider sind diese aufgrund des Packages schwer zu löten und aufgrund der Versandkosten auch leider nicht wirklich attraktiv.

Es gibt auch noch einen weiteren VOC-Sensor, der z.B. im Grove Air Quality Monitor verbaut ist: EXP TECH
Sensor ist der hier: http://www.seeedstudio.com/wiki/imag...gas_sensor.pdf
Das Board habe ich mir mal zum Spaß und für erste Gehversuche bestellt.
Hat auch ein TO-5-Gehäuse, leider gibts den TP-401A nirgends einzeln zu kaufen.

Können wir aber noch überlegen, welcher es dann letztendlich wird. Die Anbindung an den Arduino ist wirklich kinderleicht.

Bezüglich Stromversorgung des VOC habe ich mir auch schon Gedanken gemacht: es wird ein schnuckeliger DC/DC-Wandler zu 4€, der aus den 20V aus dem ASIC des TPuart ausreichend Strom auf 5V-Potential erzeugt...ist auch schon unterwegs zu mir :-)

Bezüglich Display bin ich am Schwanken...das Nokia5110-LCD wäre auch eine Alternative und mit rund 4€ spottbillig. Und es gibt jede Menge Arduino-Sketches dafür :-)
Vorteil des DOGS wäre zum einen die Industriequalität und die Möglichkeit, eine schöne "Ampel" als Hintergrundbeleuchtung zu verwenden (rot/grüne HGB). Da hatte ich mir gedacht, abhängig vom aktuellen Raumklima das Backlight grün, gelb oder rot leuchten zu lassen. Wäre sicher ein schönes Gimmick und man sieht von Weitem, ob alles ok ist. Leider sind die Displayroutinen nicht gerade einfach.

Also, es bleibt spannend...bitte nicht wundern wenn ich mal ein paar Tage hier nix im Thread schreibe, ich bin und bleibe dran :-) Das erste Hardware-Testmuster bekommst auf jeden Fall Du falls gewünscht :-)

[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 :-)

[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

[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]

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

[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.

[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

[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

[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 !

[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