ARDUINO am KNX

[l0wside]

Fuer mich ist das momentan jedenfalls wirklich ein Problem - neben der VirtualWall gehts da am selben uC bloss um 3 DS1820 und schon jetzt gehen regelmaessig Pakete verloren wenn die waehrend des Auslesens eintrudeln

Wenn ihr wollt, stelle ich meine komplett Interrupt-basierten Routinen für Onewire zur Verfügung. Die sind zwar für MSP430 geschrieben, sollten sich aber recht einfach portieren lassen.
Sie benötigen einen Timer, der beim Hochzählen zwei und beim Überlauf einen dritten Interrupt auslösen kann. Notwendige Anpassungen sind dann eigentlich nur die Konfiguration des Timers, der Aufruf des Interrupts und das Auslesen/Umschalten des Portpins.

Damit sollte das Problem erledigt sein. Ich habe nur keine Ahnung, wie man das auf den Arduino bringt.

Genervter Kommentar am Rande: Es gibt haufenweise I2C- und Onewire-Routinen im Netz. Kern aller dieser Routinen (auch des TI-Demo-Codes) ist irgend ein delay(). Was zum Teufel soll das? Das ist zwar für die erste Inbetriebnahme toll, weil es schnell läuft. Für ernsthaften Betrieb ist es aber schlicht ungeeignet. Ich habe mir den Kram notgedrungen selbst geschrieben.

Max

[wintermute]

@Greentux: misst du die RH unter der Badewanne? Ist das eine indirekte Leckage-Detektion??

Das ist eine berechtigte Frage
Aber danke, ich verstehe jetzt den Sinn hinter der parasitaeren Sache...

Ich habe vorhin noch ein ganz klein wenig rumgespielt und die Standard-1wire-Lib fuer den Arduino beisst sich scheinbar wirklich mit der KNX-Sache. Das Prinzip bei der seriellen Kommunikation beim Arduino ist halt staendig an der Schnittstelle zu haengen und zu reagieren sobald was passiert. Die 1wire-Lib spielt da gehoerig mit rein

Mal so konzeptlos in den Raum gefragt: wenn das mit I2C und 1wire nicht funktioniert (falls es bei dem konkreten Problem ueberhaupt abhelfen wuerde) - man koennte auch einfach einen zweiten Arduino Mini rein fuer 1wire abstellen und den die Werte auslesen lassen. Der "KNX-Arduino" koennte dann zB via SPI bereits verfuegbare Werte abfragen was die Laufzeit vermutlich recht positiv beeinflussen duerfte... klar, sind Mehrkosten (wenn auch vernachlaessigbar), ein paar mA mehr Strom und ein wenig mehr Raumbedarf. Die Alternative waere, die 1wire-Sache neu aufzuziehen - wenn das ueberhaupt Sinn macht, das Auslesen scheint mir doch recht timing-kritisch zu sein und eben auch ziemlich lang zu dauern

Fuer mich ist das momentan jedenfalls wirklich ein Problem - neben der VirtualWall gehts da am selben uC bloss um 3 DS1820 und schon jetzt gehen regelmaessig Pakete verloren wenn die waehrend des Auslesens eintrudeln

gruesse :: Michael

[ThorstenGehrig]

Hm - ich habe mal den 2438 (nicht von Wiregate, eins von Hobbyboard) angeschlossen und leider nicht zum Laufen bekommen.
Dann habe ich mich mal mit dem DHT22 befasst. Der kostet <10€, Messtolleranz +-2%. Daher kann ich die Frage von Wintermute nun nachvollziehen...

Ich mal mir jetzt mal einen DHT22 bestellt...

@Greentux: misst du die RH unter der Badewanne? Ist das eine indirekte Leckage-Detektion??

Gruß
Thorsten

[greentux]

Parasitär, weil man dann nur einen Draht ("1-wire") neben Masse braucht.
Wenn der Sensor beispielsweise unter der Badewanne am VL hängt und man 1m weiter eine Dose hat, ist sowas nicht mehr zu ändern

[JuMi2006]

Ich glaub man muss hier klar unterscheiden ob ich der Anwendungsfall auf die Wiederverwertung von vorhandenen Sensoren bezieht oder ob ein komplett neues "Produkt" her muss.
Den 2482-100 hab ich jedenfalls noch nicht am laufen ... aber keine Ahnung obs an der Schaltung oder dem Code liegt.

[wintermute]

Die müssen sowieso bei parasitärem Betrieb erstmal Energie speichern...

Mal bloed gefragt: wieso eigentlich parasitaer? Ziehen die dann weniger Strom?

gruesse

[greentux]

Mir würde es anfänglich reichen, wenn man alle 30 Sekunden die 1wire Sensoren abfragt. Die müssen sowieso bei parasitärem Betrieb erstmal Energie speichern...
Aber ja, sollte man als ToDo auf der Liste lassen.

[wintermute]

Bevor sich jetzt alle ganz ausgiebig mit 1wire befassen und loslaufen und Sensoren kaufen oder so sollte ich vielleicht auf einen Effekt hinweisen den ich schonmal kurz beschrieben hatte - laesst sich auch leicht reproduzieren.
Das Problem ist, dass exzessives Lesen der 1wire-Sensoren den KNX-Empfang empfindlich stoert. Mir ist das aufgefallen, als ich 2 DS1820 in "recht schneller" Reihenfolge ausgelesen habe (jeweils mit s/4 Pause dazwischen) und der Arduino waehrenddessen nicht mehr auf Read-Anfragen vom Bus geantwortet hat (auf Writes auch nicht, btw).
Ich glaube das Problem liegt in der Art begruendet wie die KNX-Lib die Daten empfaengt: standardmaessig wird via Interrupt auf einen seriellen Event gewartet und dann das entsprechende Telegramm komplett vom Bus gelesen. Kurzes Ueberfliegen der 1wire-Lib zeigt aber, dass waehrend der Kommunikation mit den Sensoren, die Interrupts deaktiviert werden - vermutlich damit das Timing nicht durcheinander geraet. Ich schaetze mal das ist der Grund, wieso der Arduino waehrenddessen den seriellen Event nicht mitbekommen hatte. Ist aber erstmal nur ein "wild guess", mir fehlte bisher die Zeit mich naeher damit zu befassen... Je nach Buslast und Anzahl an abzufragenden 1wire-Sensoren ist es dann mitunter auch schon bedenkenswert wie lang es dauert bis die 64byte Buffer des Arduinos ueberlaufen und Busdaten definitiv unwiederbringlich verloren gehen.

Natuerlich passiert das nur waehrend der 1wire-Kommunikation und wenn man das eher selten macht sinkt die Wahrscheinlichkeit des Auftretens - aber leider ist das nicht wirklich eine saubere Implementierung. Fuer ein rein passiv arbeitendes Geraet welches nur zyklisch oder bei Schwellwerten sendet ist es natuerlich egal, aber im Sinne der Fehlerfrei- und universellen Handhabbarkeit der Lib sollte vllt mal jemand versuchen ob er den Fehler nachstellen und uU sogar beheben kann - ich weiss leider nicht wann ich dazu kommen wuerde...

Vielleicht lags aber auch nur an meinem Aufbau - glaub ich aber nicht, ehrlich gesagt

gruesse :: Michael

[greentux]

Zur Umrechnung reicht ja vl. auch die Temp aus dem 2438.
Das meinte ich eben auch. Schöne Sensoren gibt es ja schon. 1Wire geht offensichtlich out-of-the-box. Sensoren gibt es damit schon mehr als genug.

Mag aber auch nur daran liegen, das ich schon ne Menge Sensoren hier verbaut habe...

[ThorstenGehrig]

Na ich glaube mit den "ungenauen" DHT11 wollen sich hier wenige Beschäftigen. Die Wiregate-Sensoren sind halt schonmal sehr gut und bereits für einen Berker-Sensoreinsatz vorbereitet.
Wobei ich Wintermute recht gebe: das Protokoll ist erstmal egal.

Die Wiregate-Sensoren laufen ja wohl auf dem "Batteriemonitor" DS2438 mit einem Honywell HIHxxx.
Also brauchen wir "nur" einen Code um den DS2438 auszulesen - und die Umrechnungsformel. Diese wierrum müsste sich sowohl im Wiregate- also auch im owfs finden lassen.
Mit diesen Begriffen hat mir Google das hier ausgespuckt:
https://code.google.com/p/gfb/source...istat.pde?r=93
Problem Sensor RH lesen damit gelößt
Umrechnen auf abs. Luftfeuchte ist dann nur Mathe - sofern man aus dem DS18S20 die Temp. auslesen kann.
Google liefert da auch Ergebnisse - aber einfache Formeln suche ich noch...

Hier die Formel:
TD: =243.04*(LN(RH/100)+((17.625*T)/(243.04+T)))/(17.625-LN(RH/100)-((17.625*T)/(243.04+T)))

TD=Taupunkt in Celsius
T=Temp in Celsius
RH=Rel. Luftfeuchte

Gruß
Thorsten

[wintermute]

Da braucht man sich keinen DHT11 antun, der ja wiederum kein 1wire spricht.

Nujo, ob ich nen Sensor nun via 1wire, SPI oder AnalogIN am Arduino anschliesse ist ja nu erstmal egal. Dass der DHT kein 1wire spricht ist IMHO absolut kein Argument - weder dafuer noch dagegen
Er ist preiswert und mit fertigen Libs zu betreiben. In meinen Augen ist das der Hauptbeweggrund die ganze Sache ueberhaupt mit nem Arduino zu betreiben: naemlich dass es einfach ist. Wenn ich alles neu erfinden muss kann ich auch irgendeinen uC mit irgendeinem TPUART an den Bus bringen - das kann im Endeffekt naemlich vermutlich mehr als ein Arduino...

gruesse

[greentux]

Naja, Taupunkt und abs. Luftfeuchte kann man ja auch noch woanders berechnen, wenn man will. Z.b. auf SH.py. Aber das wird auch da im Code gehen. Da braucht man sich keinen DHT11 antun, der ja wiederum kein 1wire spricht.

Jumi, es wäre auszuprobieren, was das Bitbanging 1wire am Arduino so "treiben" kann. Also ob man damit so eine Art dezentralen Busmaster baut oder eben in jede UP Dose, wo jetzt ein Multisensor ist, einen verbauen müsste.
Du hast parasitär probiert?

[wintermute]

Die Frage ist also eher nach fertigem Code für die Umrechnung in rF% und absol. Luftfeuchte und evtl. noch Taupunkt.

Hi Thorsten,

such mal nach Arduino Code fuer den DHT11. Das ist T/H (allerdings deutlich ungenauer als zumindest die DS1820) auf preislich ueberschaubarem Niveau. Leicht zu bekommen, inkl. fertiger Libraries fuer den Arduino, Taupunkt inbegriffen.
Ich habe ne Handvoll hier, benutze die aber nur fuer Feuchtemessungen, Temp ueberlasse ich lieber den 1820ern.

gruesse :: Michael

[JuMi2006]

Ich hab jetzt erstmal nur fertige Librarys gesucht. Die iButtons gehen ja einfach per ID und da tut es das Example schon recht gut: Arduino Playground - OneWire

Für die DS2438 gibts auch ne Library+Example, die muss man nur nochmal anpassen wegen einer Namensänderung:
https://code.google.com/p/gfb/source...arduino/DS2438

Bleibt die Berechnung von absol. Luftfeuchte und Taupunkt, aber das doch nur eine weitere Funktion im Code, kann also echt nicht hart sein. Ich hab mich da auch nicht reingekniet sondern nur mal geschaut wie schnell man ans Ziel kommt -> Sehr schnell .

[ThorstenGehrig]

Welchen Code/Library verwendest du denn für die iButtons?
Temp sind "ja klar" - bei mir ist aber auch die Frage nach einem Kombisensor/Humidity offen.
Sofern ich das recht im Kopf habe sind das ja einfache Sensoren die einen Spannungswert zurückgeben. Die Frage ist also eher nach fertigem Code für die Umrechnung in rF% und absol. Luftfeuchte und evtl. noch Taupunkt.

@Greentux: die Elab-Sensoren sind kein Problem - das ist ja "standart" 1-Wire (nur eben in "gut" gemacht :-) ) - es geht "nur" um das Auswerten.

Gruß
Thorsten