ARDUINO am KNX

[dschwert]

Seit Kurzem experimentiere ich mit ESP8266 Modulen.

Auf ESP8266 läuft auch Micropython. Das ist ggfs. auch noch eine Option, falls du lieber in Python programmierst als in C. Seit zwei Wochen lasse ich ein Pyboard an einer Siemens BCU als Proof-of-Concept laufen. Für das Pyboard mit dem STM32F405 reicht der Strom aus dem Bus ohne Probleme. Ich mache aber mit der Software erst weiter, wenn meine Platinen da sind und funktionieren (mit NCN5120 und STM32F405).

Gruß,
Dietmar

[tuxedo]

KONNEKTING hat übrigens auch Beispiel Code und eine stetig wachsende Doku. Nur so am Rande. Vielleicht lohnt es sich ja ne Stunde länger mit der Materie zu beschäftigen und gleich von einer einfachen Parametrisierung per Bus profitieren. Ach ja, Software Update via Bus steht auch auf dem Plan.

http://www.konnekting.de/konnekting-lernen/
https://github.com/KONNEKTING/Konnek...aster/examples
https://github.com/KONNEKTING/Konnek...ster/README.md

[Mag Gyver]

Was möchtest du hören?

Es gibt hier keine Absolution.

Es kommt immer auf deine Aufgabenstellung und die daraus resultierende Lösung an. Es gibt keine gute oder schlechte Version, denn es kommt sehr auf die Anwendung an. Jede Version hat ihre Stärken und Schwächen oder kann in Zusammenspiel mit anderen Librarys etwaige Schwachpunkte zu Tage treten.

Nennt man dann nicht "Bug" sondern "Feature".

Bringe als erstes doch grundlegendes zum Laufen ohne KNX/EIB-Anbindung. Sollte dies stabil laufen, dann binde die Library zur KNX/EIB-Anbindung ein und teste dies dann.

Es sind auch diverse Sketche in den derzeit 62 Seiten versteckt, auch Hinweise und Anregungen. Sowie Warnungen und Fehler.
Auch ich habe mich am Anfang einarbeiten müssen um meine ersten Projekte mit KNX/EIB-Anbindung zu realisieren.

Wünsche dir viel Erfolg bei den Projekt(en).

[ebus]

Also gut, beide Versionen sind gleich gut geeignet, gleich stabil, werden gleichermaßen weitergepflegt und es spielt keine Rolle, auf welcher ich aufsetze.

[tuxedo]

Hier traut sich keiner Tacheles zu reden. Political correctnes in Reinform. Deswegen gewinnen Trump und Erdogan Wahlen.

Wie darf man denn das jetzt verstehen? Hier wird keine Meinung der political correctness wegen unterdrückt oder zurück gehalten. Das ist einfach der aktuelle Stand.

[ebus]

Hier traut sich keiner Tacheles zu reden. Political correctnes in Reinform. Deswegen gewinnen Trump und Erdogan Wahlen.

Immerhin macht die Diskussion Mut, denn beide Versionen scheinen ja grundsätzlich stabil zu sein.

--

Was ist denn der Unterschied in den internen Strukturen?

[Mag Gyver]

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.

[intelligente Haustechnik]

Ich hab mich jetzt schon etwas länger nicht mehr damit befasst, aber Deine Wünsche sollten mit jeder Version problemlos abdeckbar sein

[ebus]

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.

[ebus]

> 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

[Mag Gyver]

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:

https://knx-user-forum.de/forum/projektforen/konnekting

DKA-DERIVAT (THORSTEN GEHRIG):

https://bitbucket.org/thorstengehrig/arduino-tpuart-knx-user-forum/src

DKA-DERIVAT (MAG GYVER):

https://bitbucket.org/MagGyver/arduino-am-knx

[tuxedo]

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.

[ebus]

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

[Eugenius]

Leider keine Zeit mehr gehabt für den Busmonitor

[Mag Gyver]

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.