KNX-Multisensor

[l0wside]

Seit gestern abend funktioniert PropertyWrite und PropertyRead (die sind notwendig, um das Gerät über den Bus zu konfigurieren).

Jetzt fehlen nur noch zwei Features:

• Die Applikation muss die per PropertyWrite gesetzten Werte auch tatsächlich verwenden
• Flashen über den Bus

Ich bin optimistisch, das in den nächsten Tagen hinzubekommen.



Die Temperaturabweichung wird vorläufig per fixem Offset (einstellbar über PropertyWrite) kompensiert. HW rev 0.7 bekommt dann einen DS18B20.



Max

[ThorstenGehrig]

Hi,
spannend was ihr hier so treibt :-) Die DIY-Sektion habe ich noch garnicht so recht wahrgenommen :-)
Ich bin gerade etwas "gröber" Unterwegs und will einen RFID an den Bus bringen.
Die "DKA"-Library scheint mir ein guter ansatz zum schreiben per Arduino (auf die Telie aus China warte ich gerade).
Wie habt Ihr den Buszugriff gregelt?
Ich habe mir den BCU 5WG1117-2AB12 von Siemens bestellt... bitte sagt mir das dieser per PIN 2+4 (R/W) die richtige Wahl war...

Gruß
Thorsten

[l0wside]

Hallo Thorsten,

der BCU-Ansatz ist sicher einfacher, vor allem, wenn man nicht scharf aufs Löten ist. Der TP-UART ist im QFN-Gehäuse, das ist nicht ganz ohne. Und auch ein kompletter Stack ist mit einigem Aufwand verbunden.
Immerhin lernt man aber bei der Implementierung "from scratch" eine ganze Menge :-)

Max

[Robert]

Na, den Stack müsste er wohl auch selber coden - die genannte Version verpackt nur den TP-UART mit Hühnerfutter in einem fertigen Gehäuse. Da ist kein weiterer (Protokoll-)Controller drauf.

Zum Entwickeln ganz nett - hinterher zu teuer und vom Formfaktor zu unflexibel.

[ThorstenGehrig]

Hi,
also wenn ich ehrlich bin: ich halte mich nicht in der Lage einen eigenen Stack zu coden. Ein "zusammenfügen der Puzzelteile" mit ein bisschen eigenem Code krieg ich sicherlich hin.

Für den Stack hoffe ich auf diese Library:
https://bitbucket.org/dka/arduino-tpuart
Leider kann die wohl noch keine 14Byte-Text-Telegramme...

Formfaktor ist bei meinem RFID nicht so dramatisch - in der Klingelanlage ist genug Platz vorhanden.
Die 35€ finde ich akzeptabel - da mir die alternative so "einfach" zur verfügung steht.

Jetzt hab ich teilweise diesen Thread gekapert - sorry dafür.
Falls ein Admin mitliest: bitte "abtrennen" und als eigenen eigenen Thread ablegen.

Gruß
Thorsten

[greentux]

Max, gibts schon was neues?

[mayrjohannes]

Hallo, ich arbeite an einem ähnlichen Projekt (siehe http://knx- user-forum.de/diy-do-yourself/32573-pic-am-knx.html) und da stellt sich natürlich auch die Frage der Parametrierbarkeit. Bisher bin ich eher den Freebus Ansatz mit gekarperten VD Files gegangen, aber der gefällt mir irgendwie nicht so. Gibt es von dem Ansatz in deinem Projekt schon mehr details?
Wie Robert schon mehrmals in verschiedenen Threads geschrieben hat wäre es sehr erstrebenswert eine Tool (von PC Seite aus) zu haben das für alle selbsgebastelten Sachen funktioniert.
Wenn es sowas in ansätzen schon gibt wäre ich auch bereit etwas Zeit zum mitentwicklen zu installieren und würde es auch gerne für mein Projekt verwenden.

[l0wside]

Max, gibts schon was neues?

Ja. Aktuell ist die HW-Version 0.7.

• Ich habe über Weihnachten - abgesehen von der regierungsamtlich verordneten Arbeitspause während der Feiertage - am Umprogrammieren über den Bus gearbeitet. Das Thema hat mich mehrere Wochen gekostet und läuft immer noch nicht anständig. Die ersten Sensoren werden das Feature also wohl nicht haben.
  Notwendig ist für das Neuprogrammieren über den Bus in jedem Fall ein gepatchter mwrite. Der bei eibd mitgelieferte kann nur 255 Bytes, das ist für ein Update ein bisschen arg wenig.
• Letzte Woche sind die Leiterplatten v0.7 gekommen. Änderungen:
  • Statt des MCP9803 (I2C) ist nun 1-Wire (DS18S20) verbaut und funktioniert auch schon ganz brav.
  • Das Layout passt nun auch tatsächlich in den Berker-Einsatz (hätte vorher nur kopfüber reingepasst)
  • Programmieradapter auf TagConnect umgestellt

Die erste Leiterplatte läuft seit gestern Abend. Ich muss aber heute abend noch den DS18S20 in die Applikation einbinden (ist keine große Sache)

• Physikalische Adresse lässt sich problemlos schreiben: Knopf drücken, LED geht an, writeaddress local:/tmp/eib 1.2.34 aufrufen, LED geht aus, fertig.
• Auch die Konfiguration funktioniert per xpropwrite. Details muss ich nachliefern.
• Geplantes Feature (in der HW vorgesehen, aber noch nicht bestückt und in der Firmware bisher nicht umgesetzt): die v0.7 hat einen DS2482-100 an Bord und kann damit weitere Onewire-Sensoren ansteuern, auch mit Strong Pullup.
  

In den nächsten zwei Wochen müssten die Lotpasten-Schablonen für die v0.7 kommen. Dann kann ich voraussichtlich einige Geräte produzieren. Wer hat Interesse?


Max



P.S.: Ich muss mal ein Bild des Leiterplattenfriedhofs posten, der sich seit v0.1 angesammelt hat.
EDIT: done. Bilder zeigen den Leiterplattenfriedhof (so weit noch nicht im Müll gelandet), Oberseite und Unterseite des Sensors (beschriftet)

[JuMi2006]

Hallo Max,

auf meiner Seite ist das Interesse groß allerdings, kurz noch mal ne Frage zu den Grundlagen.

Wie programmierst Du die Funktionen innerhalb des Sensor? Welcher Feuchte-Sensor wurde jetzt verbaut? Also irgendwer muss dem IC ja sagen was er zu tun hat und wie er das auf den Bus bringt? Ansonsten bringe ich ein bisschen Perl/Python mit und verstehe im großen und ganzen was ein C-Code anrichtet. Auch das ein oder andere Feature hinzu zu fügen ist mir schon gelungen - also lernwillig .

Kurz:
Ich würde mich gerne einbringen, vor allem um meine iButtons endlich losgelöst von 1-Wire-USB zu betreiben. Buttons und Reader liegen hier. Unkosten würde ich natürlich erstatten.

Grüße

[l0wside]

Konfigurations-Format

Wie heute versprochen, anbei die Doku des Konfigurations-Formats. In C sieht das so aus:

/* DEKLARATION */
#define KNX_FLAG_COMM 0x01
#define KNX_FLAG_READABLE 0x02
#define KNX_FLAG_WRITEABLE 0x04
#define KNX_FLAG_UPDATE 0x08
#define KNX_FLAG_TRANSMIT 0x10

typedef struct {
	uint16_t ga;
	uint8_t ko;
	uint8_t flags;
} knx_ga_map_t;

typedef struct {
	uint16_t version;
	knx_address_t phys_address;
	uint16_t interval_temp;
	uint16_t interval_humid;
	uint16_t temp_ofs;
	knx_ga_map_t ga_map[16];
} configuration_t;

typedef struct {
	uint8_t obj_id;
	uint8_t property_id;
	uint8_t size;
	uint8_t n_elem;
	void* addr;
} configuration_desc_t;


/* DEFINITION */
configuration_t configuration = {
		VERSION,
		0xFFFF,
		0,
		0,
		0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0,
		0, 0, 0
};

const configuration_desc_t configuration_desc[] = {
		{ 1,0,sizeof(configuration.interval_temp),1,&configuration.interval_temp },
		{ 1,1,sizeof(configuration.temp_ofs),1,&configuration.temp_ofs },
		{ 2,0,sizeof(configuration.interval_humid),1,&configuration.interval_humid },
		{ 0,0,sizeof(knx_ga_map_t),16,configuration.ga_map }
};

Den zugehörigen Code stelle ich gerne zur Verfügung, einfach anfragen.


Das ganze ist so zu interpretieren:

• Objekt 0: GA-Mapping (Vorschlag: immer fix auf Objekt 0)
• Objekt 1: Temperatur
  • Property 0: Sendeintervall (16 bit)
  • Property 1: Temperatur-Offset (16 bit)
• Objekt 2: Feuchte
  • Property 0: Sendeintervall (16 bit)
  
  

Die GA-Liste ist wie folgt:
16 bit GA (im gleichen Format wie auf dem Bus, also kein Unterschied zwischen little und big endian)
8 bit KO
8 bit Flags (siehe #defines)

Auf Objekt 0xFF gibt es noch Debuginfos zum Lesen, das ist aber unsupported.

Verwendung auf PC-Seite
Verwendet wird xpropwrite:
xpropwrite url eibaddr obj prop start nr_of_elem [xx xx ..]

Das Sendeintervall für die Temperatur wird wie folgt auf 60 gesetzt:

xpropwrite local:/tmp/eib 1.2.34 1 0 0 1 3C 00

Interpretation: Obj=1, Prop=0, Start=0, NoElem=1, Wert=3C00

Der Wert sieht deswegen so seltsam aus, weil Little Endian geschrieben wird, also der niedrigwertige Anteil zuerst.


Zur Unterstützung:
Ich hatte ja mal ein mögliches XML-Format skizziert. Wenn sich jemand dessen annehmen und es überarbeiten würde, wäre das schon mal gut. Auf dieser Basis wünsche ich mir dann zwei Dinge:

• Einen Generator für den obenstehenden C-Code
• Ein (mehr oder weniger) komfortables Konfigurationsprogramm. Optimalerweise grafisch, mit Unix (eibd)- und Windows (Falcon)-Support.

Wer sich aktiv einbringt, bekommt einen Sensor frei Haus (limitiert auf insgesamt 2-3 Stück, ich brauche selber auch noch welche).

Max

[l0wside]

Hallo JuMi,

au weia, ich muss ins Bett. Noch kurz:
Für Feuchtesensor und Temperatursensor, die sich auf dem KNXMS befinden, ist ein Mikrocontroller drauf (MSP430F5310, siehe beschriftete Bilder oben). Der µC liest die Werte aus (Temperatursensor über 1-Wire, Feuchtesensor über einen eingebauten A/D-Wandler) und wertet die Daten aus. Dann versendet er sie über den Bus und nutzt dazu den TP-UART2.
Diese Funktionalität ist so gut wie fertig (ich muss noch die Umstellung des Temperatursensors von I2C nach 1-Wire fertig machen, aber das ist nicht viel).

Der DS2482 (One-Wire-Treiber) ist noch nicht bestückt und damit auch nicht zu sehen. Wenn er bestückt ist, kann man daran weitere Sensoren anschließen, die der MSP430 dann auslesen kann. Für die Interpretation der Daten muss man dann C-Code schreiben, der in den MSP430 kommt. Das ist aber kein Hexenwerk.

Die Liste der gefundenen IDs würde ich als ein Objekt,das sich über xpropread lesen lässt, zur Verfügung stellen. Der geneigte Benutzer muss dann nur noch über xpropwrite mitteilen, wann und wie oft er die Daten haben will. Die Konvertierung von 1-Wire nach KNX-Format (meist DPT9) macht dann auch der µC, bei Einsatz von Wiregate, sh.py & Co erledigt das owfs.

Zeitplan dafür: naja, ich sag mal optimistisch März...

Max

P.S. für Nachfragen: ja, der eingebaute Temperatursensor und die extern anschließbaren werden auf unterschiedlichen 1-Wire-Leitungen angesteuert. Das war Absicht.

[mayrjohannes]

Das mit deiner Konfiguration des Gerätes finde ich sehr gut gelöst. Gefällt mir viel besser als die variante über ETS (natürlich nur für Eigenbaugeräte).
An der Entwicklung der PC Tools kann ich mich mangels Zeit leider nicht beteiligen. Ich werde selbes Schema aber für meine KNX Platine mit dem PIC und NCN5120 implementieren und meinen ETS Ansatz mit gekarperten VD files links liegen lassen.
Du hast sicher etwas mehr Dokument zu den "Properties" der KO. Könntest du mir da ev. etwas zukommen lassen damit ich mich etwas mehr einlesen kann.

Besten Dank

Johannes

[greentux]

Max, die Feuchte liefert dann ein HIH-4000, wobei Du auch die Temperaturkompensation damit machst?

Sollte man ggf. Code etc. mal in ein git repo tun?

[JuMi2006]

Also ich würde mich an dem tool beteiligen wollen, hatte ja schon meine Vorstellungen gepostet und denke da kommt man gut überein. Einzig GUI ist mir ein Fremdwort und auch zu Falcon/Windows kann ich nichts beitragen.

Wenn der Code mal irgendwo liegt könnte ich mal drauf schauen ob ich mir das zutraue da noch die iButtons einzubinden .

[l0wside]

Max, die Feuchte liefert dann ein HIH-4000, wobei Du auch die Temperaturkompensation damit machst?

Fast - auf dem Board ist ein HIH-5030 verbaut (SMD, siehe Bild 2 hier), der HIH-4000 ist ein bedrahtetes Bauteil. Beim Wiregate-Sensor ist ein HIH-4031 verbaut. Unterschiede: der HIH-4031 ist betauungsresistent und will 5V sehen. Der HIH-5030 ist nicht betauungsresistent (dafür etwas billiger) und ist mit 3,3V zufrieden. Man kann ihn ohne Probleme gegen den betauungsresistenten HIH-5031 ersetzen.

Die Feuchtekompensation mache ich intern im µC und verwende dazu die Temperatur des DS18S20. Das ist zwar nicht 100%ig korrekt, weil die Temperatur des Feuchtesensors nicht notwendigerweise genau identisch zur Temperatur am DS18S20 ist - da die Messgenauigkeit bei rH aber ohnehin nicht sonderlich toll ist (+/- 2%), habe ich das großzügig übersehen.

@Johannes: freut mich, wenn hier ein Standard entsteht!

@JuMi: statt GUI fände ich auch ein Wiregate-Plugin toll (auch wenn ich selbst kein Wiregate habe)

Max