Hallo, ich habe eine Klimaanlage, für die es ein KNX EIB Interface gibt (ME-AC-KNX-1-V2). Ich möchte die Klimaanlage mit meiner Haussteuerung bedienen. Ich möchte hierzu ein Interface machen, das Schnittstelle zwischen meinem Hausbus und dem KNX EIB Interface ist. Die Realisierung soll z.B. mit einem ATMEGA 168 oder ATMEGA 128 erfolgen. Für KNX gibt es ja entsprechende Transceiver for KNX Twisted Pair Networks wie z.B. der NCN5120 von ON. Der hat RxD und TxD, die man mit dem Controller verbinden kann. Ich denke hardwaremäßig hält sich der Aufwand in Grenzen. Aber der Softwareaufwand? Von Fa. Intensis gibt es eine Beschreibung zu dem KNX EIB Interface (hier sind Data type ID usw. angegeben). Kann das absolut nicht einschätzen, was da für ein Aufwand dahinter steckt. Hat jemand schon Erfahrungen mit KNX? Gruß Martin
:
Verschoben durch User
Hi Martin, ich habe das bei mir schon gemacht. Läuft seit 2006 (Hausbau) problemlos ohne Aussetzer. Ist im Grunde genommen schon trivial, der Aufwand, einzelne Geräte anzusteuern, ist sehr gering. Aufwendiger wird das natürlich in einem Gesamtkonzept. Bei mir ist die "Grundinstallation" des Hauses mit handelsüblichen KNX-Komponenten ausgeführt, also Taster, Aktoren, Bewegungs- und Präsenzmelder, Sensoren, etc., damit alles für den Fall des Falles von einem Dorf-Elektriker repariert werden kann (damit die Freundin nicht im dunklen Haus sitzt, wenn mal was defekt ist und ich mal auf Geschäftsreise bin...). Für die Komfortfunktionen, Verknüpfungen sowie die Anbindung an die Außenwelt - Ethernet und GSM - habe ich damals einen kleinen Steuerrechner auf Cortex-M3-Basis (Luminary, heute Texas Instruments) gebaut. Dieser hängt zum einen am Ethernet, zum anderen am KNX. Die GUI-Logik für die Programmierung neuer Funktionen und Verknüpfungen läuft auf einer VM auf meinem Virtualisierungshost. Dieser überträgt dann Änderungen, welche ich per Browser machen kann, auf diesen Steuerrechner. Ebenso speichert die VM sämtliche Aktivitäten in einer PostgreSQL-Datenbank zur weiteren Auswertung. Die Schnittstelle zum KNX habe ich über die SIM-KNX von Tapko gemacht: http://www.tapko.de/SIM-KNX?&L=1 Für damals knapp 80,-€ eine prima Sache. Der Anschluß an den Cortex erfolgt über den UART. Die SIM-KNX kommuniziert über ein simples Klartext-Protokoll. Man muss sich also anfangs nur die einen interessierenden Parameter der vorhandenen Geräte heraussuchen und schon kann man senden, die Gruppenadressen sind ja bekannt. Für das Empfangen gilt das Gleiche. Wenn Du es Dir besonders einfach machen willst, kannst Du ja einfach den Busverkehr mitschneiden. Dann ersparst Du Dir sogar das Zusammensetzen der einzelnen Datenpakete. Ich konnte damals schon am ersten Tag sämtliche Lampen ein- und ausschalten sowie dimmen und auch die Rolläden und Jalousien verfahren. Viel Spaß damit. Grüße, Andreas
Hallo Andreas, das SIM-KNX sieht sehr interessant aus. Ich habe noch etwas Verständnisprobleme mit dem KNX-Protokoll. Woher weiß ich z.B. die Adressen der Komponenten? Sind die aufgedruckt (wie z.B. bei Enocean-Komponenten)? Busverkehr mitschneiden geht nicht, denn ich hätte dann ja nur das Interface ME-AC-KNX-1-V2 und das SIM-KNX. Weitere KNX-Komponenten hätte ich nicht. Und was muß ich da genau senden z.B. zum Einschalten der Klimaanlage gibt es folgendes Objekt: Object #: 0 Name: On/Off [1bit] Function: 1-On, 0-Off Description: This object is used to Start (On) and Stop (Off) the AC unit Access type: Read/Write Data type ID: 1.001 Das 0 bzw. 1 für Ein- und Ausschalten ist schon klar, aber muß ich die Objektnummer oder die Data Type ID übergeben? Gruß Martin
EIB ist aus den 80'ern, also schon recht alt. Daher ist das alles auch recht einfach. Infos gibt es bei den üblichen Verdächtigen wie Freebus und Selfbus. Als Einstieg mit Atmel würde ich mir mal folgendes ansehen. https://bitbucket.org/dka/arduino-tpuart Ist aber mit TP-UART, wobei der NCN5120 im westentlichen dazu kompatibel ist.
Benötigt man zwingend die Software ETS, um die Adressen zu vergeben? Oder geht das auch anders?
:
Bearbeitet durch User
Hi! Alternativ wäre evtl. auch das hier was für Dich: http://www.weinzierl.de/index.php/de/alles-knx1/knx-module/knx-baos-modul-820 Der Vorteil ist, dass Du hier auch schon einen ObjectServer eingebaut hast. Dann kann Dein AVR per UART direkt mit den Datenpunkten des ObjectServer sprechen. Du hast dann praktisch gar nicht mehr wirklich was mit KNX zu tun. Hier ist das Protokoll für den ObjectServer beschrieben: http://weinzierl.de/download/products/870/KnxBAOS_Protocol.pdf
Zu den KNX Protokollgrundlagen siehe auch: http://www.see-solutions.de/sonstiges/KNX%20Twisted%20Pair%20Protokollbeschreibung.pdf
Hallo Martin, Ja du brauchst zum programmieren der Gruppenadressen die ETS Software. Da geht aber auch die Demo Version, die kann glaub ich max. 5 Geräte. Zusätzlich brauchst du noch einen KNX-USB Adapter zum programmieren und ein KNX-Netzteil mit Drossel, auch nicht ganz billig. KNX ist halt ein Bussystem und für eine Punkt zu Punkt Verbindung evtl. etwas oversized. Gibts keine Möglichkeit die Daten direkt an der Klimaanlage abzugreifen? Vielleicht hat darüber hier einer nähere Infos.
Ich hatte damals den eCampus besucht und dadurch eine kostenlose ETS Lite Lizenz (max. 20 Geräte) bekommen: http://wbt4.knx.org/ Ich weiß allerdings nicht, ob das mit der kostenlosen Lite-Lizenz noch aktuell ist.
Uwe schrieb: > ..und ein KNX-Netzteil mit Drossel, auch nicht ganz billig. Kann man durch einen Widerstand emulieren, wenn nur ein paar Geräte am Bus hängen: Beitrag "KNX Drossel Infos" >Ich weiß allerdings nicht, ob das mit der kostenlosen Lite-Lizenz noch >aktuell ist. Hab ich vor einem 3/4 Jahr noch gemacht...
:
Bearbeitet durch User
Uwe schrieb: > KNX ist halt ein Bussystem und für eine Punkt zu Punkt Verbindung evtl. > etwas oversized. > Gibts keine Möglichkeit die Daten direkt an der Klimaanlage abzugreifen? > Vielleicht hat darüber hier einer nähere Infos. Für die Klimaanlage gibt es diverse Module, z.B. die Schnittstelle MAC-397IF-E. Externes Ein-/Ausschalten ist laut Doku kein Problem, ebenso Betriebszustand Ein-/Aus. Die Auswahl Solltemperatur und Betriebsart scheint nur per DIP-Schalter zu gehen (es gibt hierfür anscheinend keine Klemme). Bin noch am Klären mit Mitsubishi, ob man den DIP-Schalter eventuell "anzapfen" kann. Macht aber nur Sinn, wenn dieser zyklisch und nicht nur nach dem Netzreset ausgewertet wird. In wie weit ich da von Mitsubishi noch Detailinfos erhalte, muß ich abwarten. Meine Fragen müßten sicherlich an die Entwicklungsabteilung weiter geleitet werden, da zu speziell, und denen wird der Aufwand für die Beantwortung zu groß sein....
Martin M. schrieb: > Ich denke hardwaremäßig hält sich der Aufwand in Grenzen. Aber der > Softwareaufwand? Von Fa. Intensis gibt es eine Beschreibung zu dem KNX > EIB Interface (hier sind Data type ID usw. angegeben). Kann das absolut > nicht einschätzen, was da für ein Aufwand dahinter steckt. Hat jemand > schon Erfahrungen mit KNX? Ich habe zu Fuß den KNX-Stack auf MSP430 implementiert, Aufwand im dreistelligen Stundenbereich. Für Detaillösungen geht es aber sicher auch schlanker. Ich nehme an, das war nicht ganz, was dir vorschwebte. Schau mal nach RPi und ROT-Extension (-> Google). Darauf dann ein eibd, dazu ein KNX-Netzteil mit Drossel aus der Bucht. Fertig. www.knx-user-forum.de ist auch hilfreich. Max
Hallo Max, hast du den Stack in C oder C++ implementiert und hast du die Sourcen irgendwo im Netz? Würde mich interessieren wie du das gelöst hast...
Der Stack ist in reinem C, allerdings sind die einzelnen Layer streng gekapselt. C++ wäre mir lieber gewesen, war mir für eine portable uC-Bibliothek aber zu riskant. Der Code ist nicht im Netz, Grund siehe hier: http://www.juraforum.de/forum/urheberrecht/closed-standard-open-source-461062 Max
alles klar, mir geht es jedoch nicht speziell um diesen knx stack sondern um stack implementierung im allgemeinen in C (osi layer) wo eben die layer streng getrennt sind (kein durchgreifen ect.) genau wie du es beschreibst. Mir ist leider nicht ganz klar wie man das ralisiert, vielleicht könntest du nur einen layer und dessen services veröffentlichen damit ich prinzipiell sehe wie so etwas aussieht (gerne können die spezifischen teile unkenntlich gemacht sein...) bin da schon lange auf der suche aber finde dazu nicht wirklich was passendes und wenn dann meist in C++, mir wäre damit sehr geholfen :)
Ach so, kein Problem. Ich habe es so realisiert: Jeder Layer hat seine eigenes C- und H-File. Im H-File sind die Services, die er den darüber liegenden Layern anbietet, deklariert. Diese sind alle vom Typ void, die Antwort kommt asynchron per Callback, die über Funktionszeiger realisiert sind. Außerdem hat jeder Layer noch ein void Layer_setCB(). Das sieht z.B. so aus:
1 | void(*L4_Data_con)(address_t addr, status_t status) = 0; |
2 | void (*L4_Data_ind)(address_t addr, class_t cl, sdu_t *sdu) = 0; |
3 | |
4 | void L4_setCB_Data(void(*L4_Data_con_)(address_t addr, status_t status), |
5 | void (*L4_Data_ind_)(address_t addr, class_t cl, sdu_t *sdu)) { |
6 | L4_Data_con = L4_Data_con_; |
7 | L4_Data_ind = L4_Data_ind_; |
8 | }
|
Der darüber liegende Layer definiert dann:
1 | void on_Data_con(address_t addr, status_t status) { |
2 | ...
|
3 | }
|
4 | |
5 | void on_Data_ind(address_t addr, class_t cl, sdu_t *sdu) { |
6 | ...
|
7 | }
|
und ruft in seiner Initialisierungsroutine dann L4_setCB_Data(on_Data_con, on_Data_ind) auf. In Layer 4 kann ich nun, wenn ich dem darüber liegenden Layer etwas mitteilen will, einfach
1 | if (L4_Data_ind != 0) { |
2 | L4_Data_ind(addr,cl,sdu); |
3 | }
|
aufrufen. Das ist zwar sehr modular, weil man problemlos einen Layer durch eine andere Implementierung ersetzen kann. Leider ist der Speicherbedarf auf dem Stack nicht ohne, weil jeder Aufruf erst mal Layer für Layer die Callbacks aufruft. Wenn dann noch eine Antwort Layer für Layer sich wieder abwärt wühlt, hast du 2*Layerzahl gestapelte Funktionsaufrufe auf dem Stack. Effizient ist das nicht. Beim nächsten Mal würde ich eher den Präprozessor quälen: bei Empfang eines Pakets Byte für Byte einen mittels Präprozessor aus den verschiedenen Layer-Headern zusammengebauten Baum traversieren und (so weit irgendwie möglich) vom Physical Layer dann direkt die eigentliche Applikation aufrufen. Das ist dann deutlich effizienter. Max Nachtrag: In C++ würde ich es eher so realisieren: Layer 4:
1 | class Layer4 { |
2 | public:
|
3 | (Services für Layer 5) |
4 | |
5 | private:
|
6 | Layer4CB cb; |
7 | }
|
8 | |
9 | public abstract class Layer4CB { |
10 | (Callbacks von Layer 4 nach Layer 5) |
11 | }
|
Layer 5:
1 | class Layer5 : Layer4CB { |
2 | (Services für Layer 6) |
3 | |
4 | private:
|
5 | Layer4 *layer4; |
6 | }
|
7 | |
8 | public Layer5::Layer5() { |
9 | layer4 = new Layer4(); |
10 | layer4->cb = this; |
11 | }
|
Das ist kein valides C++, aber die Idee wird hoffentlich klar: jeder Layer hat eine Klasse und zusätzlich eine abstrakte Callback-Klasse, die vom Layer darüber implementiert wird. Max
:
Bearbeitet durch User
hui danke für diese infos, so hab ich das noch gar nie betrachtet.... wenn ich das richtig verstehe wird beim Empfang über die cb rauf bis zur letzten schicht von oben herab runter gearbeitet und die daten werden von der entsprechenden application quasi abgeholt.... von oben nach unten, also beim Senden gehts direkt von schicht zu schicht?
Exakt. Physical ruft den CB von datalink auf, datalink den CB von network, ... bis irgendwann application(7) den CB der eigentlichen Anwendung aufruft. In der Regel wird die Anwendung dann im gleichen Kontext die Antwort auswürfeln und gleich senden, d.h. dieser Aufwand landet auch noch auf dem Stack. Von obenn nach unten (also Anwendung->physical) wird einfach ganz normal aufgerufen. Max
:
Bearbeitet durch User
könnte man statdessen nicht einfach die layer entkapseln, also das sie nicht ineinander verschachtelt aufgerufen werden sondern jeder layer einzeln und somit seinen stack bereich wieder freigibt bevor der nächste startet? die etscheidung welcher service in dem darüberliegenden layer ausgeführt werden soll müsste dann natürlich dort anhand des pdu des vorangegangenen layers zuerst getroffen werden. So hab ich das eigentlich bis jetzt immer im kopf gehabt, problem dabei ist das jeder layer quasi die inqueue pollen muss und ab layer 3 bekommt man dadurch je anzahl an ports, adressen, etc. entsprechend viele und es wird eine richtung bevorzugt da die reihenfolge halt fix vorgegeben ist wenn man kein os verwendet wo die layer in einzelne parallele tasks gepackt werden. probleme über probleme :) leider hab ich noch nirgends literatur zu dem thema gefunden.....
Der Ansatz ist auch ganz nett und würde das Stackproblem lösen. Willst du eine Queue für alles verwenden oder jeweils eine eigene Queue zwischen zwei Layern? Performancemäßig dürfte der Ansatz aber noch schlechter sein, weil der Hintergrundtask an jedem Layer einmal vorbeikommen muss. Außerdem musst du dann in jedem Layer die Daten erst aus der Queue herauskopieren, verarbeiten und wieder in die Queue stellen. Das bedeutet vor allem zusätzliche Laufzeit wegen viel Kopiererei. Es wäre aber mal definitiv was anderes. Du musst eben dich einmal entscheiden, was deine Designprioritäten sind: Speicherverbrauch, Laufzeit, Portabilität, Kapselung der Layer. Ist ein bisschen wie "fast, cheap, good - choose any two of them". Die fixe Reihenfolge würde mir keine Sorgen machen. Stelle doch alles in eine gemeinsame Queue, unabhängig vom Layer. Am Anfang jedes Datensatzes kodierst du, welcher Layer das bearbeiten soll. Fertig. Max
:
Bearbeitet durch User
Max G. schrieb: > Der Code ist nicht im Netz, Grund siehe hier: > http://www.juraforum.de/forum/urheberrecht/closed-standard-open-source-461062 > Die Antwort dort finde ich sehr merkwürdig. Wenn das Verfahren patentiert ist, dann sind die Patente öffentlich einsehbar. Das ist schon mal kein Argument gegen eine Veröffentlichung einer eigenen Implementierung. Weiterhin betreffen Patente Privatleute nicht, solange mit dem Werk kein Gewinn erzielt werden soll. Denk' mal an die ganzen Open-Source mp3-Implementierungen. mp3 ist ein patentiertes Verfahren! Für die kommerzielle Nutzung muss/musste ganz real Geld bezahlt werden (bis das Patent abgelaufen ist). Das ist der Grund, warum viele Player im Linux-Bereich darauf angewiesen sind/waren, dass sich der Nutzer die Bibliotheken parallel runterläd und übersetzt. Problematisch wird es dann, wenn solche Open-Source Umsetzungen auf einmal im gewerblichen Umfeld eingesetzt werden. Was evtl. problematisch sein könnte ist, wenn in der eigenen Implementierung fremde Hersteller-IDs verwendet werden, um z.B. in der ETS erkannt zu werden. Mit dem Problem kann man aber auch kreativ umgehen, siehe z.B. http://ixo-jtag.sourceforge.net/archive/ixo_de_usb_jtag.html
Hallo Florian, meine Sorge sind nicht die Patente, sondern der Urheberrechtsschutz. §53(1) 1. Satz lautet: Zulässig sind einzelne Vervielfältigungen eines Werkes durch eine natürliche Person zum privaten Gebrauch auf beliebigen Trägern, sofern sie weder unmittelbar noch mittelbar Erwerbszwecken dienen, soweit nicht zur Vervielfältigung eine offensichtlich rechtswidrig hergestellte oder öffentlich zugänglich gemachte Vorlage verwendet wird. Die Quelle ist eher dubios. Der Sourcecode ist nach meiner (völlig unmaßgeblichen, IANAL) Einschätzung eine Ableitung aus einem bestehenden Werk, damit wäre §23 UrhG einschlägig. Auf der anderen Seite bestimmt §69a(1): "Ideen und Grundsätze, die einem Element eines Computerprogramms zugrunde liegen, einschließlich der den Schnittstellen zugrundeliegenden Ideen und Grundsätze, sind nicht geschützt." Darauf könnte man sich berufen, der Standard beschreibt schließlich nur Ideen und Grundsätze, nicht die Implementierung. Insgesamt ist mir das aber zu heiß. Max
Ja, aber da steht die TU Wien dahinter. Und die ist Scientific Partner: http://www.knx.org/knx-en/community/scientific-partners/list/index.php?q=country_id=202 Max
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.