KONNEKTING Logikmodul

[STSC]

Bei der RPI fehlt mir persönlich einfach die Zuverlässigkeit. Zunächst läuft die ganze Kommunikation über IP und nicht direkt auf KNX. Dann bezweifle ich dass die microSD 10 Jahre und länger halten. Meine letzten beiden im RPI waren nach einem halben Jahr defekt.

Muss aber jeder selber wissen welchen Weg er bevorzugt...

P.S. Die MDT Logikmodule finde ich Klasse. Geht einfach und kosten nicht viel.

[ChriD]

Muss aber jeder selber wissen welchen Weg er bevorzugt...

Da stimme ich dir zu!
Beim Rest ließe sich diskutieren ;-)

[jentz1986]

Ich frage mich schon etwas länger, ob es einen eleganten Weg dafür gibt, dieserlei Dinge zu modularisieren. Entweder man entwickelt ein Produkt, dass nur einen Zweck hat (Jalousieaktor mit 8 Kanälen, Dimmaktor mit 9 Kanälen, whatever) oder man entwickelt ständig neu. Die Enocean-Hardware liegt bei mir auf dem Basteltisch. Sie funktioniert super, und wenn ich jetzt den Druck hätte, tatsächlich x Taster an den Start zu bringen, würde ich das mit der gegebenen Suite auch alles hinbekommen. Es ist aber eben so, dass ich eigentlich gerne eine schicke Modularisierung hätte: Ich designe einen Funktionsblock, der einen Enocean-Taster anbindet, einen weiteren der Feuchtigkeitssensor ausliest. Wie bringe ich das dann zusammen? Die XML generiert die .h-datei, die ich in der Arduino IDE (oder eher sloeber) mit Leben fülle. Dann spiele ich das Ganze wieder per Suite zurück, brauche aber schon wieder einen "Produktcode". Ob ich nun ein modulares Gerät gestalte, des Softwaremodule einzeln mit Hardware sprechen, oder ob es nun ein Softwaremodul ist, das nur EVA macht, ist dann egal.

Versteht das bitte nicht als "Alles Scheiße". Das ist es ganz und gar nicht. Es fehlen nur noch ein paar Schritte, nach dem die Basis gelegt ist.

Letzten Endes könnte man ein Logikmodul wie das MDT Modul wahrscheinlich auch mit Konnekting und dem SAMD21 abbilden. Das ganze ist nur eine ziemliche Fleißarbeit. Ich habe mir das ETS-Frontend dazu angeschaut, das ist schon echt gut. Das gleiche mit Konnekting zu tun ist möglich. So mächtig ist die Suite schon!

Aber wie wäre der folgende Ansatz:
Man generiert ein XML/Code aus verschiedenen fertigen Versatzstücken, die schon da sind; Am besten schon in der Suite (dadurch entstehen dann die KOs). Dann verknüpft man das Ganze mit GAs (natürlich m:n). Dann drückt man auf "Senden" in der Suite und ist stolz wie Oskar.
Ein fertiges Versatzstück kann dann ein Blockly-Interpreter sein, der dann aus Lua/python/php/... c++ macht und die entsprechenden XML-teile und den Code liefert. Oder direkt mit dem Blockly-Designer (oder MS-WF, oder ... ?) arbeitet. Aber eben die Power des PCs fürs Cross-Compilen nutzt. Ggf. ließe sich dann auch ein entsprechendes Scheduling hinterlegen, sozusagen ein Betriebssystem für Logiken. Klingt krasser als es ist.

EDIT: es hat auch schonmal einer versucht LUA auf dem Arduino Uno R3 auszuführen; Vielleicht ist das auch eine Lösung für Blockly -> Konnekting?
https://github.com/JohnMH/lua-arduino

[STSC]

Klar könnte man z.B mit Blockly C Code generieren und kompilieren. Aber dann müsstest jedes mal die komplette Firmware mit KNX übertragen. Das kann schon etwas dauern... Bei einem Interpreter bräuchtest nur das Skript übertragen.

[STSC]

Was heißt "Python Lib"?! Bisher hab ich nur gesehen, dass dieses Python Teil "exclusiv" läuft. D.h. wenn Python läuft, läuft da kein Arduino-C++-Sketch und umgekehrt.

Was wir bräuchten ist eine tatsächliche Arduino Library die es einem erlaubt Python Code (geladen von einem beliebigen Speicher (SD-Karte, separater Flash, ...) aus einem Arduino setup()/loop() Sketch heraus auszuführen. Ich habe noch nichts gefunden in Richtung Python.

Wenn wir da was finden können wir das mal zusammen mit KONNEKTING ausprobieren.

Habe mir das mal etwas genauer angesehen. Muss dir Recht geben. Prinzipiell müsste man die KonnektingDeviceLibrary überführen also Module/Lib in CircuitPython. Dann könnte man KONNEKTING direkt in Python verwenden. Ja, das ist etwas Aufwand und vor allem ist man mindestens bei einem SAMD21, wenn nicht SAMD51.
Hast du schon mal den Stromverbrauch vom M0dularis+ mit SAMD21 gemessen?

[tuxedo]

Dann könnte man KONNEKTING direkt in Python verwenden.

C++ ist halt noch schneller als Python, weswegen es in meinen Augen nicht unbedingt Sinn ergibt _alles_ auf Python umzustellen und damit noch eine weitere Abstraktionsschicht im System zu haben, die weitere Komplexität beim Debuggen und dergleichen mit sich bringt. Wir sind ja schon froh dass wir mittlerweile in der Lage sind Code-Zeile für Code-Zeile mit dem ATMEL ICE Hardaredebugger durch zu gehen und in jede Variable rein schauen können um Fehler zu finden (das ist bei der größe von Lib die wir mittlerweile haben mehr als hilfreich...). Wenn da nun Python dazu kommt.. Puuh, dann geht das von vorne los.

SAMD21 ist bei uns mittlerweile der Standard. Von den 32k RAM geht schon einiges drauf wenn man größere Geräte baut. Python würde uns hier noch weiter einschränken.

Der SAMD51 braucht zwar laut Datenblatt etwa 65µA/Mhz und der SAMD21 liegt bei "<70µA/Mhz" (also beide nah beieinander), aber der SAMD21 hat auch "nur" 48Mhz und der SAMD51 gleich 120. Macht also mehr als das doppelte im Strombedarf.

Auswendig weiß ich es nicht wo der SAMD21 genau im Verbrauch liegt. Aber laut Datenblatt sind es knapp 5mA für einen Fibonacci-Algorithmus. Der SAMD51 braucht dann also rund 2,5x mehr. Irgendwas um 12,5mA.

Typischerweise sagt man: 50mA vom Bus. Max. 100mA vom Bus.

Das alles klingt jetzt nicht dramatisch. Aber nur weil wir Python für die Logik ausführen wollen 2,5x mehr Strom fressen... ich weiß nicht. Ich bin skeptisch.

Ich würde da eher schauen ob es noch doch noch einen netten Python-Interpreter (oder einen anderen) als Arduino-Lib gibt die man einbinden kann. Dann würde KONNEKTING mit "FullSpeed C++" laufen können und das bisschen Logik was man umsetzen will läuft dann ggf. etwas langsamer.

[MGK]

Als scriptsprache embedded würde sich wohl am ehesten Lua anbieten, das ist im Prinzip für so was gemacht. (Lua ist im wesentlichen ein Satz C libraries) Siehe https://www.lua.org/ddj.html
Auf Arduino wird das allerdings ressourcenmässig bestimmt „interessant“

[tuxedo]

Ich frage mich schon etwas länger, ob es einen eleganten Weg dafür gibt, dieserlei Dinge zu modularisieren. Entweder man entwickelt ein Produkt, dass nur einen Zweck hat (Jalousieaktor mit 8 Kanälen, Dimmaktor mit 9 Kanälen, whatever) oder man entwickelt ständig neu.

Das was du da suchst ist die modularisierung des Codes. Es macht absolut 0 Sinn alles in den Sketch zu stecken... Vieeel Spaghetti-Code. Das ist nicht wiederverwertbar.
Stattdessen sollte man den Code so bauen, dass man ihn wiederverwenden kann.
Ich hab das für den Roto-Aktor schon probiert. Ist noch nicht perfekt, aber ein Anfang.
Im Roto-Aktor steckt ja ein Port-Extender-IC der die notwenidge Anzahl an IOs für das Ansteuern der 8 Bistabilen Relais liefert. Der Code lässt sich wiederverwenden und findet auch in der frontendplatine mit den 8 tastern und den LEDs Anwendung.

Das ist aber nichts was ich auf Anwenderseite "modular" haben will. Denn der Anwender will nur sein Gerät parametrisieren.

Die Sache mit der Logik: Ja, hier hat die Suite noch potential. Es wird in Beta5 die Möglichkeit geben "Files" auf die Geräte zu laden. ich brauche das z.b. für meine smarte Türklingel wo ich Textansagen abspielen lasse wenn ich nicht daheim bin, oder auch "klingeltöne" wenn klingelt.

Das kann man dann auch für die Logiken verwenden. Logik mit einem Tool zusammenbauen in in der Suite einfach "hochladen".

Aber dafür braucht es eine Lib die so eine "Logikdatei" lesen und innerhalb des Sketches ausführen kann. Wer da etwas cooles und passendes findet das vielversprechend ist, dem kann ich ggf. ein "M0dularis" zur Verfügung stellen um einen Proof-of-Concept zu bauen.

[STSC]

KONNEKTING mit "FullSpeed C++" laufen können und das bisschen Logik was man umsetzen will läuft dann ggf. etwas langsamer.

Das wäre ja auch bei CircuitPython so, dass KONNEKTING in C bleibt, aber man es trotzdem in Python z.B. für eine Logik verwenden kann.

Aber egal, ich gebe jetzt erst mal auf. Habe jetzt lange im Internet recherchiert. Das Python ist generell einfach etwas zu groß für den Arduino... und alle anderen Interpreter fand ich uninteressant.

[jentz1986]

Lua auf Arduino: siehe oben.

Zwecks Modularisierung sollte man sich mal fragen was das Produkt, und wer der Anwender ist. Wir haben hier lauter Bastler und kreative Spezialisten. KNX-„Profis“ und WAF-Fanatiker werden nicht mit Konnekting agieren. Daher sollte IMHO nicht das statische Produkt das Ziel (in Konkurrenz zu MDT Gira und co) sein, sondern der Aufbau eines starken und leicht erlernbaren Entwicklerframeworks für die Kreativen...

[Eugenius]

Eine andere Möglichkeit wäre: Es gibt master MCU die sich mit "KNX" Beschäftigt und es gibt eine slave MCU für den Script.
Aber da wären wir wieder beim 2x Stromverbrauch, 2x Firmwares. Anzahl von KOs wäre dann konstant, da master MCU nicht umprogrammiert wird... und und und.

Ich habe vor ca. 1,5 Jahren angefangen einen Mini-Logikmodul zu bauen (so ähnlich wie MDT Logikmodul). Allerdings wurde der Code so was von übersichtlich, dass ich es gelassen habe. Da muss man mit mehrerern Klassen arbeiten und soooo wichtig war es für mich doch nicht, da ein OpenHAB Server eh ständig läuft und da kann ich mich viel flexibler mit Logiken beschäftigen.

Lasst und zuerst die Lib zum finalen Stand bringen. Wir sind quasi 1,3 Personen (wobei Alex 1,1 und ich 0,2) die sich mit dem Library Code beschäftigen... Privatleben haben wir auch noch. Und es zahlt keiner für diese Arbeit... Somit sitzen wir in der Freizeit nach der Geldbringender Arbeit wieder am PC und coden weiter... Familien "freuen" sich :/

Und übrigens, es werden später nicht nur Files über KNX Übertragen, sonden auch komplette Arduino Firmware. D.h. man kann die "Logik" direkt in der Arduino IDE als c++ code programmieren. Speichert die Firmware auf die Festplate. Öffnet die Firmware in der Suite und lässt die auf gewünschtes Gerät (das irgendwo im Haus in einer Unterputzdose hinter einer Steckdose, die hinterm einem Schrank in dunklem Keller versteckt ist) übertragen
Ja, es wird ein paar Minuten dauern. Aber dafür müsst ihr nicht ins dunkle Keller laufen, keinen Schrank schieben, keine Steckdose ausbauen und dann auch noch das Gerät ans PC hängen und wieder zurück

Und das beste ist, jedes Gerät, das genug Flash hat (z.B. SAMD21) oder jedes Gerät mit SPI Flash lässt so updaten (Wir haben das zwar bis jetzt nur mit SAMD21 mit und ohne SPI Flash getestet, aber ich werde dann auch noch STM32 MCUs ergänzen. Über die anderen MCUs haben wir uns noch keine Gedanken gemacht).
Man muss sich nur ein wenig gedulden...

[Eugenius]

Lua auf Arduino: siehe oben.

Zwecks Modularisierung sollte man sich mal fragen was das Produkt, und wer der Anwender ist. Wir haben hier lauter Bastler und kreative Spezialisten. KNX-„Profis“ und WAF-Fanatiker werden nicht mit Konnekting agieren. Daher sollte IMHO nicht das statische Produkt das Ziel (in Konkurrenz zu MDT Gira und co) sein, sondern der Aufbau eines starken und leicht erlernbaren Entwicklerframeworks für die Kreativen...

Das werde ich so nicht ganz unterschreiben. Wir haben hier auch Arduino Anfänger, die bis Konnekting nicht mal wussten, dass es Arduino gibt. Solche Anwender wollen nur Parametrieren, aber nichts mit Software anfangen. Ich würde sogar sagen, dass bis jetzt ca. 90% der Anwender einfach ein fertiges Device ala MDT/GIRA/co. haben wollen.

[tuxedo]

Ich glaube ich muss hier nochmal einwerfen wo wir mit KONNEKTING versuchen anzusetzen:

KONNEKTING wurde aus dem Bedarf heraus geschaffen, DIY KNX Geräte mit "konfigurierbarkeit" zu versehen. Dann kam schnell die Frage auf, welche Zielgruppe man bedienen will. Zielgruppe nicht allein auf Entwickler fokusiert, sondern auch auf Anwender.
Es macht keinen Sinn den tausendsten Schaltaktor zu bauen, der das gleiche kann wie die 999 zuvor. Ziel ist es Nischen zu finden und diese mit DIY Geräten zu besetzen, weil die großen Hersteller keinen Markt in diesen Nischen sehen. KONNEKTING hat nicht den Anspruch existierende Geräte direkt nachzuahmen, oder billiger zu sein wie diese. Das funktioniert wenn, dann mit mit Qualitätsabstrichen. Und das wollen die wenigsten.
Ein Beispiel für dieses besetzen von Nischen ist der Roto Aktor (also quasi ein fertiges Produkt das es so noch nicht gibt), oder Eugen's MI (eine "Plattform" für eigene Projekte, die es so auch noch nicht gibt).

Beides findet nicht nur anklang, sondern es entstehen daraus auch neue Ideen.

Daher sollte IMHO nicht das statische Produkt das Ziel ... sein

Wieso nicht? Beispiel Roto-Aktor: Eine Kerntruppe die es betrifft entwickelt es, die anderen können es einfach nachbauen, oder sich von der Gruppe mit fertigen Geräten versorgen lassen. Damit ist allen geholfen.

sondern der Aufbau eines starken und leicht erlernbaren Entwicklerframeworks für die Kreativen...

Eines das ich in den vergangenen Jahren gelernt habe ist: Es gibt nicht die eine Plattform die jedem Entwicklerstand gerecht wird um Geräte zu basteln. Wer nur schnell ein Gerät für sich basteln will und ein recht spezifisches Problem zu lösen, der hat vielleicht auch kein interesse dran das Gerät später über ein Tool einstellen zu können. So jemand nutzt dann das andere KNX Projekt hier im Forum: kleiner Arduino, Siemens BCU dran und nen Sensor, fertig. Kein aufwendiges XML... einfach machen.
Wer aber ein programmierbares Gerät entwickeln will, der MUSS sich einfach mit der Materie beschäftigen. So jemand muss wissen welche Parameter sein Gerät haben soll, muss sich mit Datentypen beschäftigen, mit Geräte-Flags und Co.
Python oder eine andere Sprache wird an der "erlernbarkeit" nichts ändern. Denn irgendwie muss man sein "Gerät" ja formell beschreiben. Das passiert bei uns eben in XML. Gründe für XML findet man hier im Forum und auch im KnxTpUart vs. KONNEKTING Thread hinreichend viele.
Arduino an sich ist keine wirklich schwere sprache. Für vielerlei Sensoren oder Problemchen gibt es fertige Code-Snippets oder Projekte wo man abschauen kann. Das wirklich "komplizierte" ist die Konzeption einer Geräteanwendung: Sprich: Wie verheirate ich meinen Sensor (oder was auch immer) mit KNX. Hier spielen wieder Datentypen eine Rolle, und auch die XML die das Gerät beschreibt. Man braucht wissen über das Timing (ist die Sensor-Abfrage schnell, oder blockiert diese für 2-3sek bis ich einen verlässlichen Wert habe?) und wie eben alles zusammenspielt. Das wird mit Python und Co. auch nicht einfacher. Solche Themen adressiert man entweder mit KnowHow das man aufbaut, oder eben mit mehr Leistung und MultiThreading. Aber solange es keine bezahlbaren Multi-Core Microcontroller gibt die man idealerweise vom Bus aus versorgen kann wird das schwer. Aktuell zeichnet sich aber ein erster Trend Richtung Dual-Core Microcontroller ab. Aber auf Dauer muss man dennoch mit dem Strom vom Bus haushalten. Ja, man kann auch über gelb/weiß versorgen, aber einige haben gelb/weiß z.B. schon für 1-wire belegt.
Wenn es "exoten" gibt die extern Versorgt werden müssen: Okay. Aber die Basis sollte halt doch noch vom Bus laufen.

Bevor ich jetzt ganze Romane schreibe: Ich bin prinzipiell offen für alles. Aber es ist ja nicht so dass wir uns nicht erst seit gestern mit der ganzen Thematik beschäftigen. Einige Punkte die wir hier diskutieren haben wir teils schon mehrfach besprochen, und das Ergebnis war fast jedesmal das selbe.
Dennoch bin ich froh über diese Anregung, die dieses mal wieder neue Aspekte rein gebracht hat und auch gezeigt hat, dass hier wieder eine kleine Bedarfsecke zu entstehen scheint, die man ggf. noch adressieren kann oder auch muss.

Wenn es konkrete Probleme mit KONNEKTING gibt oder Ansätze nicht klar sind: Bitte offen ansprechen und auch Details nennen. Wir sind bemüht das alles zu (er)klären.

[ChriD]

Gehört zwar nicht wirklich rein aber weil du Multithreading auf Microcontrollern erwähnt hast.
https://www.riot-os.org/

Leider hatte ich noch keine Zeit mich damit zu beschäftigen :-(
Ahhh es gäbe so viel schönes Zeugs und so wenig Zeit :-)

[STSC]

Ja, es ist richtig KONNEKTING erst zu einem finalen und stabilen Stand zu bringen. Hochachtung was ihr da auf die Beine stellt. Trotzdem kann man ja ein paar mögliche zukünftige Ideen diskutieren.

Ich hätte noch einen komplett anderen Satz für ein Logikmodul. Könnte man nicht fix 8KB oder 16KB vom EEPROM/FLASH für ein C-Objekt reservieren. Dieser Code müsste dann zur Laufzeit ausgeführt ausgeführt und ggf. davor vielleicht noch ins RAM kopiert werden. 8KB oder 16KB sollten sich relativ schnell mit der Suite hochladen lassen und man müsste nicht die komplette Firmware übertragen.