Ankündigung

Einklappen
Keine Ankündigung bisher.

ARDUINO am KNX

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Ing-Dom
    antwortet
    Und es gibt sie doch, die Neulinge die sich durch die 40Seiten wühlen. Hat mich zwar den gestrigen Abend gekostet aber habe viel gelernt.

    Richtig geil was hier geschaffen wurde! Da ich schon ATMega Erfahrung habe liegt mir das Thema ein wenig näher als die selfbus-Truppe mit ihrem 89LPC922 bzw. ihrem ARM-Nachfolger.
    Für "große" Geräte gefüllt mir diese Lösung hier besser, weil wohl robuster und weil man den Mega gut skalieren kann.
    Selfbus hat halt nen klaren Preisvorteil, 11€ für nen Universalschnittstelle für UP mit µC und Busanbindung ist schon echt günstig.

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Vielleicht noch ein weiteres Linux-Board das dem Arduino konkurrenz machen könnte: http://vocore.io/

    Einen Kommentar schreiben:


  • l0wside
    antwortet
    Zitat von tuxedo Beitrag anzeigen

    Bin aus dem Bereich "Elektronik" schon ne Weile raus. Aber wieso findest du dass die ADUMs "tatsächlich ziemlich groß" sind? 5,0x6,2mm sind nicht sooo riesig. Und welcher Optokoppler (von der mangelhaften bestromung durch den Bus mal abgesehen) wäre da noch kleiner/platzsparender?
    OK, ich hatte den (von mir mal verwendeten) ADUM1402 im Kopf gehabt, der hat rund 10x10mm. Die 5x6mm des ADUM1201 (der hier ausreicht) sind dagegen ja richtig überschaubar.

    @Mirko: der Berker erlaubt 28x32mm Leiterplatte. Das müsste eigentlich gehen, schon in Anbetracht deiner winzigen LEDs Den Taster kannst du noch durch ein Reed ersetzen, und statt der Schaltreglerdrossel einen kleinen Linearregler (aus V20 gespeist) verwenden.
    Worst case: von 0603 auf 0402 gehen und Vierlagenlayout (mit KiCad) verwenden.

    Mangelnde Motivation ist bei dem schönen Wetter draußen allerdings nachvollziehbar...auch ein kleiner Garten will versorgt werden.

    Max

    Einen Kommentar schreiben:


  • JuMi2006
    antwortet
    Eigentlich schweben mir 2 Varianten auf einer Platine vor. Adum optional.

    Variante 1:
    Arduino + Zubehör werden ohne galvanische Trennung aus dem Bus (TPUART) versorgt. (Ohne Adum)

    Variante 2:
    TP-UART wird über den Bus gespeist. Arduino und Zubehör erhalten separate SV von extern. (2x Optokoppler RX+TX oder 1x Adum)

    Mir fehlt momentan schlichtweg Zeit und Lust. Auf einem Berker wird das sehr eng, aber vielleicht kann man im Arduino-Teil noch was wegsparen oder muss wirklich klein werden. Ansonsten würde mit momentan auch einfach ein Design reiche das in eine Gerätedose passt. Im Vergleich zum Rest der Teile ist der Adum eben wirklich ein Riese.

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Zitat von l0wside Beitrag anzeigen
    Die ADUMs sind tatsächlich ziemlich groß, und Optokoppler lassen sich mit den Strömen aus dem Bus nicht so richtig gut treiben.
    Bin aus dem Bereich "Elektronik" schon ne Weile raus. Aber wieso findest du dass die ADUMs "tatsächlich ziemlich groß" sind? 5,0x6,2mm sind nicht sooo riesig. Und welcher Optokoppler (von der mangelhaften bestromung durch den Bus mal abgesehen) wäre da noch kleiner/platzsparender?

    Einen Kommentar schreiben:


  • l0wside
    antwortet
    Zitat von JuMi2006 Beitrag anzeigen
    Da scheitere ich momentan aber noch am Layout weil ich die Option für galvanische Trennung zwischen KNX und Arduino unterbringen will. Dazu natürlich noch der passende USB-Anschluss zur Programmierung.
    Wie willst du die Spannungsversorgung für den Arduino machen? Galvanisch getrennter Schaltregler, oder externe Versorgung?

    Die ADUMs sind tatsächlich ziemlich groß, und Optokoppler lassen sich mit den Strömen aus dem Bus nicht so richtig gut treiben.

    Max

    Einen Kommentar schreiben:


  • JuMi2006
    antwortet
    Ich komme im Moment nicht so 100% dazu. Mein ehrgeiziges Ziel war ja einen eigenen Arduino mit TP-UART in Berker-Größe zu bauen.
    Da scheitere ich momentan aber noch am Layout weil ich die Option für galvanische Trennung zwischen KNX und Arduino unterbringen will. Dazu natürlich noch der passende USB-Anschluss zur Programmierung.

    Also überlege ich momentan ein neues Layout.

    Das Shield hab ich hier mehrfach funktionsfähig rumzuliegen, funktioniert also als Prototyp - ohne galvanische Trennung. Es fehlt: Zeit, oder jemand der gern mit Eagle malt. Schaltplan ist soweit zusammen, es muss "lediglich" geroutet werden. Dann kann ich bestellen, bestücken und testen ...

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    @JuMi2006

    Wie schaut's mit dem Shield aus?


    Mit dem Arietta G25 ... Bin da echt kurz davor mal so ein teil zu bestellen und zu schauen, wie gut da Java mit Calimero läuft.... Wäre doch eine feine Sache.

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Ich habe in etwa die selben Bedenken wie die Selfbus-Jungs: Passt der ganze Stack-Overhead noch in den uC?!

    Klar, man könnte auch einen Raspi oder dergleichen nehmen. Aber die sind nicht so schön klein wie ein Arduino Micro+ESP8266. Wäre aber deutlich performanter und man könnte eibd oder Calimero als Bus-Zugang benutzen...

    Wobei: Im Zuge eines anderen Projekts (Dimplex Wärmepumpe über Modbus und Calimero KNX-fähig machen + Dimplex KWL über RS485 und Calimero KNX-fähig machen) bin ich am überlegen ob ich die Calimero-Lib nicht mal "abstrahiere" und ein einfaches API mit den wichtigtsten und gängigsten Features basteln soll.. Dann wäre der Weg für "Software-KNX-Devices" nicht mehr so steinig...Damit wäre zumindest der Pi und Co. eine einfache mögliche Lösung. Passt nur leider in keinem Fall in eine Unterputzdose. Müsste man mal schauen was so der kleinste ARM mit Netzwerk/WLAN ist der noch anständig Java-Programme ausführen kann (habs - abgesehen von Arduino - nicht so mit C/C++....)


    [update]
    http://www.acmesystems.it/arietta
    Das wäre sehr klein. 400Mhz und 256MB Ram sollten eigentlich passen ... WIFI kommt als AddOn oben drauf: http://www.acmesystems.it/arietta_wifi und macht das ganze nur unwesentlich größer...
    Müsste man mal probieren...

    Die 256MB Version inkl. WiFi Modul und Steuer und Versand nach DE liegt bei 66,64EUR. Nicht billig, aber möglich...
    Zuletzt geändert von tuxedo; 11.03.2015, 09:45.

    Einen Kommentar schreiben:


  • jaykay
    antwortet
    Bei Selfbus gab es schon mal eine Anfrage, aber nichts konkretes. Die Idee mit dem WLAN finde ich auch interessant aber meine ToDo Liste ist auch zu lang ;-)

    Hallo zusammen, mich würde interessieren, was Ihr von KNX IP only Geräten halten würdet, die per WLAN angebunden sind und einen ESP8266 benutzen. Hintergrund: Es gibt ja inzwischen komplette WLAN-Module mit dem ...

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Hat schon mal jemand drüber nachgedacht den Arduino nicht per Siemens BCU sondern per Netzwerk an den Bus zu bringen (IP/Router vorausgesetzt)?

    Bin zufällig hierüber gestolpert: http://www.amazon.de/dp/B00FR7DX0K/r...I2118WNL5VPTEH

    Haken:

    1) Stromversorgung ... geht über Netzwerk nur mit POE. Dafür aber mit "mehr Power"
    2) "große Netzwerkleitung mit 'aufwendigem Stecker'" statt einfacher, 4-adriger KNX Leitung
    2.1) Nur da einsetzbar wo eine Netzwerkleitung liegt
    3) Fehlende KNX-Library (quasi ein 'eibd' für Arduino)...

    Vorteile:

    1) nur rund 5EUR statt rund 35EUR für die Busankopplung (wenn man den IP/Router nicht mitrechnet)
    2) etwas kleinerer Aufbau als mit dem Siemens BCU
    3) Alternative Installationsort ohne KNX-Leitung möglich


    Es gibt auch günstige WLAN-Module: http://www.ebay.de/itm/ESP8266-ESP-0...item43d7b19c96

    Die werden aber mit AT-Commandos (wie in guten alten Modem-Zeiten) gesteuert. Bei Amazon gibt's die auch schon für 5EUR inkl, Versand (http://www.amazon.de/Demarkt-ESP8266...ywords=ESP8266)...

    Meine Bastel-ToDo-Liste ist zu groß um auch hier noch etwas zu starten. Finde das Thema aber dennoch interessant...

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    @JuMi2006
    Hier mal mein Umbau der KnxTpUart Lib ... --> http://denbh000.dyn.root1.de/public/..._tuxedo.tar.gz

    Werde es demnächst mal auf meinen SVN Server stecken und ein Redmine-Projekt ins leben rufen. Das Original Repo mit Bitbucket+Mercurial ist mir zu doof. Wenn dann vllt. Github als Alternative.

    Zum Umbau: Wie gesagt....
    * PA und GA Strings zugunsten der 2-byte Repräsentation entfernt --> Spart einiges an RAM. Speziell bei vielen GAs.
    * Aber es gibt Macros (siehe ) mit denen man doch wieder die String-Repräsentation nutzen kann.

    Macht hier in da auch Sinn wegen wegfallender Umrechnung. z.B. wenn die PA aus dem EEPROM kommt:

    Code:
        int pa0 = EEPROM.read(EEPROM_INDEX_PA);
        int pa1 = EEPROM.read(EEPROM_INDEX_PA+1);
    
        // only handle valid values, otherwise keep default
        if (pa0!=0x00 && pa1!=0x00) {
            individualAddress[0] = pa0;
            individualAddress[1] = pa1;
            knx.setIndividualAddress(individualAddress);
        }
    Das byte-Array für die PA kann man aber auch über das Macro on-the-fly erzeugen:

    Code:
    PA_INTEGER(area, line, member)
    oder
    Code:
    PA_STRING("1.1.15")
    Gleiches für GA.

    Daneben ist noch das Property-Handling dazu gekommen. Ist aber noch ungetestet.

    Nächste Schritte werden sein:

    1) Fixen des Geräte-Resets... Liegt vielleicht an meinem Source, vllt. aber auch am Stand der KnxTpUart-Implementierung
    2) Einbau von memwrite und memread
    3) testen von property + mem Implementierung

    Einen Kommentar schreiben:


  • tuxedo
    antwortet
    Zitat von l0wside Beitrag anzeigen
    Den Fehler hatte ich auch schon, das Problem scheint auf eibd-Seite zu liegen, er vergisst wohl gelegentlich, den Reset zu senden. Irgendwo habe ich noch ein mrestart2.c herumliegen, das kannst du bei Bedarf haben.
    Allerdings verschluckt (jedenfalls bei mir, ich verwende ein Weinzierl 730 IP-Gateway) der Busmonitor gelegentlich Pakete, dem Busmonitor muss man also auch nicht alles glauben.
    Für "gelegentliches Verschlucken" und "vergisst wohl gelegentlich" ist das ganze aber äußerst stabil zu 100,00% reproduzierbar. Ich hab das jetzt sicher schon 50x durchprobiert. Jedesmal ist das Verhalten exakt gleich. Mit dem arduino-Stack geht's nicht, mit der MDT Wetterstation geht's. Als IP-Zugang kommt der ABB IPR/S 2.1 IP-Router zum Einsatz.

    Wenn irgendwas "gelegentlich" nicht geht, dann sollte es doch binnen 50 Tests mal auftreten, oder?
    Hab den Busmonitor noch nicht so oft verwendet. Nur für diese Tests bisher. Aber Pakete wurden offenbar noch keine verschluckt Zumindest habe ich sonst keine vermisst.

    Das ist das System Status Byte. Siehe Martin Köglers BCU-Doku: https://www.auto.tuwien.ac.at/~mkoeg...dex.php/bcudoc

    Ignoriere du den Fehler doch einfach (ist nur unschön, aber ansonsten unproblematisch). Ansonsten kannst du auch einen rudimentären Handler für MemoryRead implementieren, der nur auf 0x60 antwortet und ansonsten die Antwort verweigert (Länge der Antwortdaten auf Null setzen).

    Max
    Danke für die Info. Mal schauen wie ich das handhabe.
    Hatte gehofft in der EIB-Doku beim Überfliegen ein Ablauf-Plan zu finden der die verschiedenen Szenarien aufklärt. Aber so wirklich fündig bin ich nicht geworden. Die Kögler-Doku geht bei mir nur in der PDF Version. Die CHM öffnen sich zwar, aber ich krieg keine Seite angezeigt. Ist das bei anderen auch so?
    [update]
    mit dem "kchmviewer" lässt sich's öffnen und komplett lesen. Nur der Viewer der mit Windows mit kommt hat Probleme ... Windows mal wieder ....

    Einen Kommentar schreiben:


  • l0wside
    antwortet
    Zitat von tuxedo Beitrag anzeigen
    Aber wie man im Screenshot sehen kann, wird im Arduino-Fall gar kein Reset ausgelöst. Ich gehe davon aus dass die ACK Meldungen nicht rechtzeitig aufschlagen?!
    In beiden Fällen habe ich per eibd (mrestart local:/tmp/eib x.y.z) den Reset ausgeführt.
    Den Fehler hatte ich auch schon, das Problem scheint auf eibd-Seite zu liegen, er vergisst wohl gelegentlich, den Reset zu senden. Irgendwo habe ich noch ein mrestart2.c herumliegen, das kannst du bei Bedarf haben.
    Allerdings verschluckt (jedenfalls bei mir, ich verwende ein Weinzierl 730 IP-Gateway) der Busmonitor gelegentlich Pakete, dem Busmonitor muss man also auch nicht alles glauben.
    Zitat von tuxedo Beitrag anzeigen
    P.S. beim PA schreiben hapert's noch daran, dass der eibd ein memoryread auf adr=0060 haben will, meine arduino aber (noch) gar kein memory-read implementiert hat... Weiß jemand warum eibd da noch Adresse 0060 vom Gerät lesen will? Was sollte da stehen? hab hier noch keinen Vergleich mit einem echten KNX Gerät gemacht...
    Das ist das System Status Byte. Siehe Martin Köglers BCU-Doku: https://www.auto.tuwien.ac.at/~mkoeg...dex.php/bcudoc

    Ignoriere du den Fehler doch einfach (ist nur unschön, aber ansonsten unproblematisch). Ansonsten kannst du auch einen rudimentären Handler für MemoryRead implementieren, der nur auf 0x60 antwortet und ansonsten die Antwort verweigert (Länge der Antwortdaten auf Null setzen).

    Max

    Einen Kommentar schreiben:


  • keldan2
    antwortet
    Zitat von tuxedo Beitrag anzeigen
    @Keldan2

    Beim groben überfliegen sieht's so aus als müsste das so funktionieren. Unterschätze aber den Aufwand nicht.
    Hallo Tuxedo,

    vielen Dank für deine Meinung.

    Ich denke ich werde das ganze mit einem Raspberry PI versuchen. Der liefert ab Werk USB und Ethernet, somit spare ich mir die Wandlung nach seriell RS232 und den Moxa.

    Nach vielen Googeln, bin ich auf Gleichgesinnte gestossen->

    Granding RFID + Fingerprint

    die zur Auswertung des Wiegand Codes die SW PiDoorman nutzen und angeblich ist es möglich aus dem RPI dann http-Requests zu erzeugen die ich im HS auswerten könnte.

    Ich weiss nur nicht ob ich direkte IP Ports zuweisen kann für Adressierung im HS ??

    Mal schauen-> Jugend forscht ;-)

    Werde berichten, wenn du noch Ideen hast immer her damit.

    LG und Danke
    Daniel

    Einen Kommentar schreiben:

Lädt...
X