Ankündigung
Einklappen
Keine Ankündigung bisher.
ARDUINO am KNX
Einklappen
X
-
Änderungen an der Library eingestellt, unter anderem:- Verzögerung zwischen dem Senden von Paketen an den Bus -> Neuer Wert = 100ms (Millisekunden)
- Beschreibungen geändert und ergänzt
- Beispiele mit der "Testkonstellation" versehen
- Einige Texte (Kommentare) aus dem Deutschen ins Englische übersetzt -> Na gut, war ein Übersetzungsprogramm!
Wer Fehler und / oder Rechtschreibfehler findet, der darf die gerne mit nach Hause nehmen.
Kommentar
-
Die optimierte Library V 1.0 !
https://bitbucket.org/MagGyver/arduino-am-knx.git
Grundlage ist die Library von tuxedo.
Leider nicht kompatibel zu der von ThorstenGehrig, muss ich gestehen.
Auch wenn es mit der IDE kompiliert, da kommt nicht das Erwartete am TP-UART raus.
Da hier die Übergabe der physikalischen Adresse und der Gruppenadressen von außen mit 3x Integer erledigt wird, aber intern wird mit Bytearray gerechnet. Alle DPT, die die Library von ThorstenGehrig unterstützt hat werden bis auf die Ausnahme DPT 3 auch durch die optimierte Version unterstützt. Hatte noch keine Zeit für die Umsetzung von DPT 3, nicht das Jemand meint das würde nicht mehr mit der optimierten Version funktionieren.
Getestet mit IDE 1.8.1 von Arduino.cc + Arduino Uno bzw. Mega + 5WG1 117-2AB12
Info (GroupWrite.ino , ohne Debugausgaben):
DanielKleinAlbers Library:- 5598 Bytes
- 7560 Bytes
- 5326 Bytes
Keinesfalls wird die Optimierung bzw. Pflege der Library von ThorstenGehrig aufgegeben. Danke auch an tuxedo, der schon sehr vieles in seiner Version berücksichtigt hat.
Bei Käfern bitte den Kammerjäger rufen, nein natürlich hier posten oder per Pull requests direkt auf bitbucket.
Kommentar
-
Kommentar
-
Es ist nicht nur lesbarer, sondern es braucht natürlich auch weniger Code (10 bis 12 Bytes Code werden gespart).
Nun, wie sieht denn deine Art Busmonitor für Daten im RAW-Format nun aus, bist du da schon weitergekommen?
Die Anregung geistert mir auch schon eine Weile im Kopf herum. Habe diesbezüglich schon mal einen Ansatz unternommen, ist jedoch sehr Alpha. Basiert auf der Library von ThortenGehrig.
Habe die Library von ThorstenGehrig und die optimierte Version angepasst.
Danke auch dir Eugenius.
Kommentar
-
Hallo Leute,
interessantes Thema. Bin ein begeisterter Selbermacher mit 10 Jahren EIB (damals hieß das so) und EBUS im SmartHome. Seit Kurzem experimentiere ich mit ESP8266 Modulen. Hat mal jemand versucht, statt einem Arduino eben ein Board auf dieser Basis zu verwenden (ESP-xx). Will es auf jeden Fall probieren. Wenn es aber bereits Erfahrungen gibt, wäre ich dankbar.
Von dka/arduino-tpuart gibt es leider schon etliche forks. Am besten gepflegt scheinen die Versionen von TG und von MagG zu sein. Mal grundsätzlich, das ist nicht förderlich, hier an mehreren Stellen weiterzuentwickeln. Tut Euch zusammen und konsolidiert eine Version draus.
Ich will jetzt nicht 60 Seiten dieses Threads durchlesen, welches die bessere Version ist. Sondern ich will loslegen: Löten und Anwendungen programmieren. Ich trau mich ja kaum zu fragen, weil ich keine weitere Diskussion anstossen will, aber welche Version ist die Beste? (Beste = Fehlerfreier, vollständiger und Ressourcen schonender (Reihenfolge entspricht meiner Priorität))
Euer
EBUS
Kommentar
-
Man merkt dass du noch nicht lange im Forum mitliest ;-)
ESP8266 wurde schon verwendet. Läuft aber wegen seinen Strombedarfs nicht ohne Klimmzüge direkt vom Bus versorgt. Auch mit abgeschaltetem WLAN säuft er beim start kurzzeitig >100mA was den KNX Transceiver so ins Straucheln bringt, dass er zusammen bricht und alles von vorne beginnt.
Welche Lib für dich die beste ist hängt davon ab was du machen willst. Willst du "mal eben schnell einen Sensor und Co. an den Bus hängen", nimm ein DKA Derivat. Am besten das was sich gerade herauskristallisiert HAT.
Willst du ein KNX "Gerät" entwickeln (also mit ProgTaste und parametrisieren über den Bus und Co.) , nimm KONNEKTING (mehr dazu auf konnekting.de oder in unserem Sub-Forum).
Eine "Beste" Variante gibt es genau so wenig wie es DAS BESTE Betriebssystem (Linux, Windows, MacOSX, ... ), oder DAS BESTE Auto (Audi, BMW, Mercedes, Porsche oder auch Dacia...) gibt. Alle haben ihre Vor- und Nachteile, sowie ihre Zielgruppe.
Kommentar
-
Na aber Fragen sind doch immer gestattet!
Da stimme ich tuxedo vollkommen zu, die Version muss zu dir und deiner "Aufgabe" passen.
Da sich alle Versionen, egal ob DKA, DKA-DERIVAT oder KONNEKTING einem stetigen Wandel unterliegen, wird es nie eine Beste geben.
Die Version von ThorstenGehrig (DKA-DERIVAT) wird nach wie vor weiterentwickelt und aktuell gehalten, daran bin ich auch mitbeteiligt. Da wird nichts an mehreren Stellen weiterentwickelt, auch wenn dies so vorkommt.
Aufgrund von Anregungen/Wünschen habe ich die Version "TUXEDO VOR KONNEKTING" angepasst und unter der Version "OPTIMIERTE LIBRARY" zur Verfügung gestellt.
Einen Anspruch auf Vollständigkeit, Fehlerfreiheit oder dergleichen ist hieraus nicht abzuleiten. Die Versionen sind so wie diese gerade sind. Den Rest kannst du selbst anpassen, falls notwendig und es wird hier Keiner gesteinigt, wenn er Fragen haben sollte!
KONNEKTING:HTML-Code:https://knx-user-forum.de/forum/projektforen/konnekting
HTML-Code:https://bitbucket.org/thorstengehrig/arduino-tpuart-knx-user-forum/src
HTML-Code:https://bitbucket.org/MagGyver/arduino-am-knx
Kommentar
-
> Man merkt dass du noch nicht lange im Forum mitliest ;-)
Du hast fast recht. Seit langem mal wieder. Und damals gab es Arduino & Co am EIB noch nicht.
Strombedarf beim Start ist mir bewusst. Das Ding zieht teilweise über 600mA beim Start (bei 3,3 V DC). Stromversorgung ist sowieso heikel, der ESP hat nur ein dünnes Band mit dem er stabil funktioniert. Aber das Stromversorgungsproblem habe ich für mich bei anderen Basteleien gelöst.
Und ja, ein DKA Derivat muss es sein. Habe nichts anderes erwähnt. Ich will kein EIB Gerät entwickeln. Wenn ich vom Besten rede, dann spreche ich daher genau von einem DKA Fork. Und da hier die Code-Basis und der Funktionsumfang so ziemlich identisch ist, kann man wohl kaum von Audi vs. Mercedes, noch nichtmal von 1,8l vs. 2,0l reden.
Ich vermute mal, dass es von Dir auch einen Fork auf github gibt. Zumindest lässt der Name den Schluss zu. Aber der ist ja seit 2 Jahren unverändert, also tot. Aktuell ist nur die Version von TG und die von MagG gepflegt.
Anders gefragt, ist die Version von TG oder die von MagG die bessere? Und zur Vereinfachung definiere ich besser nochmals neu: Besser = wird von der Mehrheit der Anwender mit Zufriedenheit eingesetzt.
Danke
EBUS
Kommentar
-
Also DKA Derivat passt zu meiner Idee. Welche es gibt, ist mir auch klar. Aber mit welchem Fork ich anfangen soll ist unklar.
Aber da Ihr so drauf rumreitet, hier in kurzen Worten was das Gerät tun soll.
Kombigerät:
4 Aktorkanäle (4 von 8 PCF8574A Kanälen)
2 Binäreingänge (weitere 2 PCF8574A Kanälen)
1 Analogeingang (1 von 8 PCF8591 Kanälen)
Hart codierte Adressen kein Problem. Es wird also keine ETS Funktionalität benötigt.
Also muss das Ding neben Binärein- und ausgänge (DPT1) auch 2 Byte Values (DPT9) mit READ, WRITE, RESPONSE bedienen können.
Das ganze wird eine erweiterte Zisternensteuerung mit Überflutungsschutz und automatischer Nachladung aus einem Brunnen.
Kommentar
-
Zur Information, beiden Versionen sind auf ihre Art und Weise gesehen für deine Anwendung verwendbar.
Der Unterschied zwischen den beiden Versionen liegt in der internen verwendeten Struktur.
Bei jedem DKA-DERIVAT sind "Beispielsketche" dabei. Die warten nur darauf von dir angepasst zu werden.
Kommentar
Kommentar