Konnekting-Anfänger: Macht es Sinn, mein Projekt überhaupt zu beginnen?

[mumpf]

Hi,

ich habe bisher mit Konnekting nichts gemacht, mit Arduino nur Kleinigkeiten und da auch nur die „kleinen“ UNO benutzt. Bin somit blutiger Anfänger. Trotzdem geht mir ein Projekt nicht aus dem Kopf, das ich gerne realisieren möchte: Ein Logikmodul mit möglichst vielen einfachen Logiken, die es ermöglichen, den gesamten Signalweg des KNX-Telegramms zu beeinflussen (also Ein-Ausschaltverzögerung, Treppenlicht, Blinken, nur EIN- bzw. nur AUS-Senden, etc.). Also kein Hardwaregerät im klassischen Sinne. Und bevor Fragen kommen, warum das Ganze nicht in einer Logikengine oder ein fertiges Modul kaufen: Ich habe beides, und beide Ansätze haben Nachteile: Bei der Logikengine ist diese erst nach dem Booten da (das dauert mir zu lange) und beim gekauften Modul hängt man komplett vom Hersteller ab und hat häufig wenige Logikkanäle und häufig sind Lösungen – wenn es überhaupt geht – nur mit mehreren Kanälen (und somit relativ teuer) möglich. Und wenn was nicht geht, ist man aufgeschmissen…

Ich habe jetzt das gesamte Wochenende hier bei euch im Konnekting-Forum gelesen und habe festgestellt, dass euer Ansatz viele Aspekte beinhaltet, die ich gerne hätte: Parametrierung über die Suite, Programmierung über den Bus, Einfluss auf die Firmware. Ich habe mich auch mal an die Suite gesetzt und mir ein passendes kdevice.xml gebastelt (für einen Logikkanal), um auch abschätzen zu können, was alles geht und was nicht. Alles bisher mit beta4b. Auch das Wiki hab ich jetzt durch, bin mir aber immer noch nicht sicher, ob ich in diese Richtung gehen sollte, deswegen hier ein paar Fragen…

Zuerstmal vorweg: Ich möchte pro Logikkanal viele Freiheitsgrade erlauben, aber nur simpelste Logiken abbilden. Komplexität soll – wenn überhaupt – durch Kombination der simplen Kanäle erfolgen. Somit möchte ich möglichst viele Kanäle unterbringen, die alle immer nur 2 Eingänge und einen Ausgang haben, also 3 KO. Bei 256 möglichen KO würde man auf rund 80 Kanäle kommen, das wäre spitze. Und bei einer geschickten Implementierung für ein Kanal könnte man alle anderen über einfache Offsets realisieren. Über die Implementierung mache ich mir relativ wenig sorgen. Aber…

• Ich würde gerne verschiedene DPT für Ein- und Ausgänge zulassen. 6 für Eingänge, 7 für Ausgänge. So wie das derzeit in der kdevice.xml gemacht wird, müsste ich (6 + 6 + 7) * 80 KO = 1520 KO definieren (kein Problem, kann ich generieren). Über viele KO wurde schon im Forum diskutiert und es gibt die Idee, dass nur die genutzten übertragen werden. Hab ich in der Suite nicht gefunden. Gibt es das schon? Oder kommt das erst zu beta5?
• Ich bin derzeit bei dem einen Kanal, den ich mal in der kdevice.xml ausprobiert habe, bei 42 Parametern angekommen. Das wären bei 80 Kanälen 42 * 80 = 3360 Parameter. Hier widersprechen sich die Informationen. An einer Stelle stand, dass man beliebig viele Parameter haben kann, solange die in den Speicher passen, anderer Stelle stand was von 256. Ersteres fände ich gut, letzteres wäre gleich ein KO-Kriterium, denn 256 Parameter reichen gerade mal für 5 Kanäle…
• Wenn man Logiken parametrieren will, braucht man Parameter, Parametergruppen und KO, die von anderen Parametern abhängen. Das kann man auch in den Dependencies ausdrücken. Ich hätte allerdings erwartet, dass ein Parameter/-gruppe/KO von mehreren anderen Parametern abhängen können, sonst kann man nicht alle Abhängigkeiten ausdrücken. Ein Beispiel, das nicht geklappt hat:
  

  	<ParameterDependency ParamId="7" Test="gt" TestParamId="6" TestValue="00"/>
  	<ParameterDependency ParamId="8" Test="gt" TestParamId="6" TestValue="00"/>
  	<ParameterDependency ParamId="9" Test="gt" TestParamId="6" TestValue="00"/>
  	<ParameterDependency ParamId="10" Test="gt" TestParamId="6" TestValue="00"/>
  	<ParameterDependency ParamId="8" Test="gt" TestParamId="7" TestValue="00"/>
  	<ParameterDependency ParamId="9" Test="gt" TestParamId="7" TestValue="00"/>

  Parameter 8 und 9 hängen von Parameter 6 und 7 ab. Die Abhängigkeit von 7 funktioniert, 6 wird nicht beachtet. Nehme ich 7 weg, funktioniert 6 ohne weiteres. Selbes Problem gibt es bei der ComObjectDependency. ParameterGroupDependency habe ich nicht getestet. Bei mir wäre das wichtig, vor allem, um das passende KO für die Eingänge und den Ausgang zu ermitteln, sollen ja nur 3 aus dem möglichen 19 sein…
• Mehrere GA pro KO sind ja für beta5 angedacht, aber ich verstehe nicht, wieso es bei 256 möglichen KO nur 256 GA geben können soll? Ich hätte mindestens das 2- oder 3-fache an GA erwartet.
• Bisher habe ich nur in der kdevice.xml die Möglichkeit gefunden, Flags für die KO einzustellen. Geht das in der Suite nicht oder finde ich es nur nicht? Ist doch eine User-Einstellung, genau wie die GA? Man möchte doch das Lese-Flag setzen können oder das Übertragen-Flag entfernen. Und auch das Aktualisieren-Flag oder das I-Flag will ich doch als User beeinflussen… Klar, Schreiben-Flag und Kommunikation an sich will man normalerweise nicht verändern… Hier scheine ich irgendwas in eurem Konzept nicht gelesen/gefunden zu haben, würde mich über einen Link zum nachlesen freuen…
• Ich habe auch gelesen, dass Konnekting-Geräte nicht auf die GA hören, die sie selber senden. Ist das immer noch so oder war das nur zu einer früheren Beta? Ich halte das für falsch und bei einem Logikmodul mit vielen Kanälen ist es eigentlich essenziell, dass man den einen Ausgang mit 1-n weiteren Eingängen verbinden kann, aber da kann ich auch für „interne“ Ein- und Ausgänge sorgen (jubel, noch mehr Parameter). Allerdings sehe ich hier auch für ein eher klassisches Konnekting-Gerät wie z.B. einen Schaltaktor unschöne Seiteneffekte: Ich kann nicht über den Statusausgang des einen Kanals einen weiteren Kanal schalten…
• So als Anmerkung: Ich gehöre auch zu den Leuten, die alle 31 Hauptgruppen nutzen! Geht das schon bei der GA-Vergabe?
• Ich habe gelesen, dass ein KO mit einem I-Flag ab beta5 nur noch 1 mal ein Read-Request sendet. Wann denn? Wer stellt sicher, dass das angefragte Gerät schon da ist und antworten kann? In meinem Logikmodul möchte ich das Lesen der Eingangswerte konfigurierbar machen, ob und wann gelesen wird. Idealerweise pro Kanal… ich gehe mal davon aus, das man über das Coding auch Read-Requests losschicken kann…

So, das war jetzt mehr als ich dachte, wahrscheinlich habe ich trotzdem noch was vergessen. Und bevor sich die Punkte oben zu kritisch anhören: Ich finde es irre, was ihr da aufgebaut habt, meine absolute Hochachtung! Ich bin mir eben nicht sicher, ob ich auf diese Plattform setzen sollte, wobei es auch keine Alternativen gibt

Gruß, Waldemar

[Masifi]

Wauh du hast ja einiges vor. Es ist ein cooles Projekt, aber deine Anforderungen sind für ein "Konnekting-Anfänger" schon hoch, auch an die Anforderungen der Suite.
Wenn du das durchziehen willst, dann gebe ich dir einen Tipp :-) fange lieber etwas kleiner an und wenn das tut, dann baue es aus.

Ich habe auch gelesen, dass Konnekting-Geräte nicht auf die GA hören, die sie selber senden. Ist das immer noch so oder war das nur zu einer früheren Beta? Ich halte das für falsch und bei einem Logikmodul mit vielen Kanälen ist es eigentlich essenziell, dass man den einen Ausgang mit 1-n weiteren Eingängen verbinden kann, aber da kann ich auch für „interne“ Ein- und Ausgänge sorgen (jubel, noch mehr Parameter). Allerdings sehe ich hier auch für ein eher klassisches Konnekting-Gerät wie z.B. einen Schaltaktor unschöne Seiteneffekte: Ich kann nicht über den Statusausgang des einen Kanals einen weiteren Kanal schalten…

Ich bin mir jetzt nicht sicher und vielleicht weiß das auch jemand anders besser, aber ich glaube nicht, dass das technisch so ohne weiteres möglich ist. Die Kommunikation zum KNX-Phy läuft über UART(SERIAL) und das sollten im µC Controller zwei getrennte "Buffer" sein. D.h. es könnte nur noch der KNX-PHY darstellen und hier bin ich mir nicht sicher ob er das kann/tut.
Ich selber nutze noch wenig "fertige" KNX Device :-) können andere KNX Device das !?

[mumpf]

Hi,

Wauh du hast ja einiges vor. Es ist ein cooles Projekt,

Danke für die Blumen - aber eigentlich ist das gar nicht so herausfordernd für das Coding. Es geht nur um eine Art Pipeline, die das KNX-Telegramm beeinflusst:
Eingang irgendein DPT (schon was Zahlenmäßiges) -> Auswertung von Vorbelegungen bei Systemstart -> Umwandlung in ein Bool über Intervallvergleich -> Negieren (ja/nein) -> AND/OR/EXOR mit den anderen Eingängen -> Auswertung wann der Ausgang der Logik Folgeaktionen triggern soll -> Treppenlicht/Blinken -> Ein-/Ausschaltverzögerung -> Zyklisch senden (getrennt für EIN oder AUS) -> Ausgangs-KO beschreiben, je nach DPT mit passendem Wert für EIN bzw. AUS, hier soll auch DPT16 (14 Byte String) gehen.

Das ist relativ einfach zu programmieren und für jeden Kanal gleich. Wenn man die Parameter und KO geschickt anlegt, ist es identisch für 1, 5 oder 80 Kanäle. Nur lohnen sich 1 oder 5 Kanäle nicht. Ich hab mal bei mir geschaut: Ich habe derzeit 86 2-Wert-Logiken aktiv, wild verstreut über irgendwelche KNX-Geräte, und je nach Gerät haben die im Detail unterschiedliches Verhalten. Dazu kommen noch die 22 (von 24 möglichen) Logikkanäle vom MDT Logikmodul, wobei da aber komplexere Sachen abgebildet werden, die hier gar nicht Thema sind. Das alles über ein Modul abzubilden, das alles kann und bei dem man sich nicht dem Wolf sucht, um die passende Funktionalität zu finden, wäre schon super - und wahrscheinlich nicht nur für mich sondern auch für andere interessant.

Wenn du das durchziehen willst, dann gebe ich dir einen Tipp :-) fange lieber etwas kleiner an und wenn das tut, dann baue es aus.

Ja, natürlich würde ich es erstmal für 2 Kanäle programmieren, basierend auf einem   #define KANALANZAHL 2;  und dann auf 5 Kanäle erweitern, um die Bugs rauszuholen, die sich eingeschlichen haben, weil man was nicht von der Konstante abhängig gemacht hat. Der Rest ist dann aber Suite und Library. Die Frage wäre: Wollt ihr in Zukunft mit so vielen Parametern/KO umgehen können (ich hätte dann auch rund 240 (+-2) ParameterGroups)? Vielleicht erst zu 1.0? Dann hätte man ja mit meinem Ansatz ein leicht skalierbares Testgerät .
Es muss natürlich nicht alles am Anfang funktionieren und ich werde sicherlich auch nicht super schnell sein - ist ja alles Hobby hier. Aber ohne eine Perspektive von min. 50 Logikkanälen im Final würde ich wahrscheinlich nicht anfangen.

Ich selber nutze noch wenig "fertige" KNX Device :-) können andere KNX Device das !?

JA! Hier würde ich sogar "selbstverständlich" sagen. Ein Schalter hat z.B. ein schalt-KO (Ausgang) und eine Status-LED (Eingang). Wieso sollte ich das Schalt-KO nicht mit der Status-LED verbinden können? Und nein, da reicht es nicht, die Status-LED intern zu parametrieren, weil man mit mehreren GA auf dem LED-Eingang auch noch andere Situationen mit der LED visualisieren kann...

Irgendwo im Forum stand auch, wie das in den Geräten gemacht wird (ich finde es aber leider nicht wieder). Grundprinzip: Beim senden auf eine GA wird geräteintern geschaut, ob noch andere KO diese GA tragen und das Schreiben-Flag gesetzt haben. Diese KO werden nach dem senden dann intern mit dem Wert auch beschrieben.

Gruß, Waldemar

[mumpf]

Hi,

ich hätte noch eine Anregung für die Suite, resultierend aus meinen ersten Versuchen . Es wäre schön, wenn man interne (also Suite-Lokale) Parameter hätte, die man dann zur Bezeichnung der Gruppen und KO nutzen kann.
Konnekting-Suite-Logik1.PNG
Konnekting-Suite-Logik2.PNG
Also statt statischen Texten sollte der User einen Begriff wählen können, den man dann in den ParameterGroup.Name und ComObject.Name bzw. ComObject.Function verwenden kann, idealerweise noch mit weiterem konstanten Text kombinierbar. Da diese Parameter nicht zum Device übertragen werden müssen, könnten sie auch normale Strings sein ohne Längenbeschränkung. Eine weitere Anwendungsmöglichkeit sehe ich auch zur Kommentierung von Einstellungen für den User. Und als dritte Möglichkeit - wenn es Readonly wäre - dann auch, um längere Hilfstexte zu einem Parameter im UI unterzubringen.
Ich könnte mir vorstellen, dass das auch unabhängig von meinem Projekt zur Verbesserung der Suite führen würde, da man so auch Kanäle von Schaltaktoren, einzelne Tasten etc. benennen könnte.

Gruß, Waldemar

[tuxedo]

aber eigentlich ist das gar nicht so herausfordernd für das Coding.

Jein ....

Was du willst, sind "universelle KOs". KOs die also je nach Einstellung den einen oder anderen DPT haben können.

Unsere Lib sieht das aber nicht direkt vor. Man muss jedem KO im Code sagen was für ein DPT es hat. Denn dementsprechend wird Speicher im RAM dafür reserviert.
Du kannst natürlich auch bei allen KOs vom Worst-Case ausgehen und den größten DPT einstellen den du findest (z.B. DPT16.001). Das hat nur eben zwei Auswirkungen:

1) Den Speicherverbrauch steigt ggf. enorm (gut und gerne Faktor 14). Hier wäre definitiv ein SAMD mit 32k RAM zu empfehlen wenn es viele KOs werden
2) Du musst dich selbst drum kümmern aus dem für den KO reservierten Speicher den passenden Datentyp wieder rauszulesen.


Hab eben gesehen dass du von 1520KOs sprichst... Prost Mahlzeit. 1520 x 14 bytes WorstCaseDPT = ~21kbyte RAM

Das haut selbst mit dem SAMD nicht hin. Denn 1520 KOs wollen ja auch noch verwaltet und gefunden werden. Da reichen die verbleibenden 11kbyte RAM des SAMD nicht aus.

Und mal so ganz nebenbei: So viele KOs können wir gar nicht:
https://wiki.konnekting.de/index.php...01#System_Type

255 KOs sind das aktuelle Maximum. Ich meine sogar, dass viele käufliche KNX Geräte da nicht mehr können (die Zahlen von uns sind ja nicht von ungefähr).
Und es kommt noch dazu, dass nur 255 GA->KO Zuweisungen möglich sind.

All das kostet eben RAM, und der ist auch beim SAMD "begrenzt". In den EEPROM/Flash kann man das nicht legen, das wird zu langsam. Denn du musst zur Laufzeit die Mapping-Tabelle entsprechend auflösen. Wenn du da erst noch durch EEPROM/Flash iterieren musst (vor allem in der Größenordnung) hast du schon wieder Telegramme auf dem Bus verpasst.

Zu deinen Parametern... 3360 Stück. Wenn jeder Parameter nur 1 byte groß ist, sind das weitere 3kbyte RAM. Gut, du kannst auch immer alles aus dem EEPROM/Flash lesen, aber da leidet wie geagt das Timing darunter. Und Timing ist das A und O bei KNX.

Alles in allem: Das funktioniert in der Größenordnung nicht. Ich bezweifle auch etwas, dass das Sinn-haft ist. Alles in allem klingt nach nach einer prima Lösung für eine Logik-Engine einer Visu oder dergleichen. Da lässt sich das deutlich einfacher realisieren und es wird einfacher von der Benutzung her.


Sorry für die schlechten Nachrichten.

[mumpf]

Hi,

vielen Dank für die ausführliche Antwort. Eine Sache würde ich gerne noch erklären:

Was du willst, sind "universelle KOs". KOs die also je nach Einstellung den einen oder anderen DPT haben können.

Die Lösung, an die Du denkst, ist ein KO, dass seinen DPT in Abhängigkeit von einem Parameter ändert. Ich denke aber an z.B. 7 KO „Ausgang“ mit unterschiedlichen DPT, die nur zur Designzeit (Suite) vorhanden sind und die über Regeln (ComobjectDependency) ausgeblendet werden können. Alle ausgeblendeten KO werden NICHT an das Device übertragen. Somit könnten die 7 KO die gleiche KO-Nummer haben, wenn man sicherstellt, dass immer nur 1 KO sichtbar bleibt. Die KO „überlagern“ sich sozusagen. Das würde in meinem Ansatz (pro Logische Funktion nur 2 Eingänge und 1 Ausgang) dann 80*3 = 240 KO machen und damit auch max. 240*14 Bytes = 3360 Bytes machen.

Unabhängig von meinem Vorhaben halte ich das für ein vernünftige Erweiterung…

Ich habe jetzt mal alternativ mit dem Projekt von thesing versucht, meine Vorstellungen in eine knxprod zu gießen, und das sieht vielversprechend aus. Vor allem, weil die ETS solche Parameter- und KO-Überlagerungen unterstützt (derzeit 31 KO pro Kanal in der knxprod, aber nur 3 KO pro Kanal im Device). Und in der ETS kann man auch Parameter "überlagern" und so Speicherplatz sparen. Ob thesing das implementiert hat, weiß ich natürlich nicht. Einen Vorteil in seinem Ansatz sehe ich auch noch: Man kann die Funktionalität der Firmware erstmal mit Linux testen (incl. ETS parametrierung), bevor man das Ganze auf einen ESP8266 oder einen SAMD bringt…

Danke und Gruß,
Waldemar

[henfri]

Bin gespannt!

[mumpf]

Hi Hendrik,

ich habe zwar ein Coding für mein Logikmodul (noch ungetestet) und eine knxprod, die richtig nett in der ETS aussieht (da kann man sich in dem XML richtig austoben), aber ich muss jetzt noch viel lesen und probieren, um das zusammen zu bringen und einen ersten POC auf nem RasPi oder einer VM zu machen. Da hoffe ich dann, gut debuggen zu können. Erwarte nicht zu viel...

Außerdem dachte ich, das wäre nichts für Dich - Du hattest irgendwo mal geschrieben, dass Du die KNX-Logiken und deren Parametrierung nicht so magst und deswegen lieber auf Logikengines setzt...

Gruß, Waldemar

[tuxedo]

Hi,

vielen Dank für die ausführliche Antwort. Eine Sache würde ich gerne noch erklären:



Die Lösung, an die Du denkst, ist ein KO, dass seinen DPT in Abhängigkeit von einem Parameter ändert. Ich denke aber an z.B. 7 KO „Ausgang“ mit unterschiedlichen DPT, die nur zur Designzeit (Suite) vorhanden sind und die über Regeln (ComobjectDependency) ausgeblendet werden können. Alle ausgeblendeten KO werden NICHT an das Device übertragen.

Puuh, ich verstehe worauf du hinaus willst. Aber in der Implementierung hat man immer noch das Problem, dass dort _alle_ KOs, aktiv oder inaktiv, bekannt sein müssen. Bisher verwenden wir hier "1 byte" um die ID der KOs zu pflegen. Wenn wir mehr als 256KOs brauchen (da zählen also auch die Inaktiven rein), dann muss sich auf jedenfall der ID-Datentyp ändern. Das zieht eine größere Änderung nach sich.
Und das setzt sich auch in der Mapping-Tabelle im RAM fort. Denn dort hab ich dann nicht nur 1 Byte für die ID, sondern zwei bytes.

In in der Association-Table brauche ich dann pro Zuweisung auch ein Byte mehr (https://wiki.konnekting.de/index.php..._Memory_Layout), eben weil die ID dann 2 bytes statt 1 byte hat.

Das ganze ist also verzwickt. Wenn wir support für mehr als 255KOs einbauen, stört das die projekte, die wenige KOs haben, weil dort mehr RAM verbraucht wird.

Man müsste wohl die Lib "spalten" und versionen für kleine und größe Geräte haben. Aber der Verwaltungsaufwand ist auch nicht ohne, zumal wird ja (leider immer noch) im beta Stadium sind und irgendwann mal eine erste stabile Version 1.0.0 haben wollen.

Aber ich habe den "Bedarf" gesehen und mache mir da mal weiter Gedanken zu. Vielleicht fällt mir da noch was ein.

[tuxedo]

Außerdem dachte ich, das wäre nichts für Dich - Du hattest irgendwo mal geschrieben, dass Du die KNX-Logiken und deren Parametrierung nicht so magst und deswegen lieber auf Logikengines setzt...

Ich persönlich sehe da auch nicht den Bedarf für Logik-Module in HW. Ja, ich sehe den Vorteil. Die Dinger laufen stabil und stürzen nicht ab.
Aber mit reiner und/oder/nicht/wasweißich Logik bekomme ich meine Logiken die ich im Haus habe nicht abgedeckt. Zumindest nicht so, dass ich das nach 6 Monaten noch verstehen würde. Da sind auch mir dann Logik-Engines lieber. Allem voran meine eigene Logik-Engine in der man Logiken selbst in Java schreiben kann und nix compilieren muss.

Bsp:

DeepinBildschirmfoto_Bereich auswählen_20190509150605.png

aber gut, das ist ein anderes Thema :-)

[mumpf]

Hi,

Aber ich habe den "Bedarf" gesehen und mache mir da mal weiter Gedanken zu. Vielleicht fällt mir da noch was ein.

hier muss ich Dich selbst zitieren, denn in Post https://knx-user-forum.de/forum/proj...94#post1008994 hast Du das schon mal analysiert. Bevor ich meine Fragen gepostet habe, hatte ich ja fast alle Beiträge gelesen, und da Deine Analyse von 2016 war, wollte ich einfach nur wissen, ob ihr das schon inzwischen macht.

Aber in der Implementierung hat man immer noch das Problem, dass dort _alle_ KOs, aktiv oder inaktiv, bekannt sein müssen.

Das sehe ich nicht so. Nach der Parametrierung wäre genau ein KO 42 übrig, und genau dieses KO 42 wird mit seinem DPT übertragen. Die Implementierung weiß auch nur vom KO 42, und in einem Parameter steht, welchen DPT diese 42 hat.

Ändert man später in der Parametrierung den DPT, dann wird auch ein anderes KO 42 aktiv, aber es ist immer noch das KO 42 für die Implementierung.

Und zum Thema Logik in KNX oder in einer Logikengine: Auch in benutze eine Logikengine für Verschattung und komplexere Steuerungen (alles, was eher Zustandsmaschinen erfordert). Aber gerade so ein Ding wie heute Morgen: Wenn Luftfeuchte bei 100% und Präsenz, dann Speigelheizung per Treppenlicht 5 Minuten einschalten -> so was will ich nativ in KNX haben. Ist aber Einstellungssache...

Gruß, Walemar

[tuxedo]

hier muss ich Dich selbst zitieren, denn in Post https://knx-user-forum.de/forum/proj...94#post1008994 hast Du das schon mal analysiert. Bevor ich meine Fragen gepostet habe, hatte ich ja fast alle Beiträge gelesen, und da Deine Analyse von 2016 war, wollte ich einfach nur wissen, ob ihr das schon inzwischen macht.

Das von mir damals geschilderte Szenario betrifft aber nicht die in der Arduino-Konnekting-Lib enthaltene Datenhaltung.
Die KONNEKTING Lib für den Arduino ist von vorne bis hinten darauf ausgelegt, dass alle aktiven und inaktiven KOs "bekannt" sind.

Das sehe ich nicht so. Nach der Parametrierung wäre genau ein KO 42 übrig, und genau dieses KO 42 wird mit seinem DPT übertragen. Die Implementierung weiß auch nur vom KO 42, und in einem Parameter steht, welchen DPT diese 42 hat.

Fast korrekt. Aktuell wird _alles_ übertragen/kommuniziert, also auch das inaktive. Hier habe ich aber schon vorbereitet dass nur noch ein Delta zur letzten Programmierung übertragen/kommuniziert wird. Das beschleunigt den Parametrisiervorgang ungemein. Aber wie gesagt: Aktuell ist es so, dass KONNEKTING Arduino seitig darauf ausgelegt ist, dass "bekannt" ist was das Gerät für KOs hat. Die "Programmierung" (die viel eher eine Parametrisierung ist), übermittelt nur noch die Einstellungen der KOs bzw. deren GAs und eben die KO unabhängigen Einstellungen (Startup-Verzögerung z.b. oder die Zeit für die Treppenlicht-Automatik).
Das ist nicht nur bei uns so, das ist auch bei offiziellen Geräten so. Habe das so aus dem BCU SDK "extrahiert" und abgeschaut.

Die Arduino-seitige Implementierung umzustellen, so dass dort erstmal KEIN KO bekannt ist solange nichts parametrisiert wurde, käme einem kompletten rewrite gleich.
Alle mir bekannten KNX Geräte (offizieller Natur) kennen intern alle ihre KOs und bekommen über die ETS nur noch deren Einstellung. Die KOs liegen im Device im RAM in "Tabellen" und werden beim Gerätestart mit den Einstellungen (die nach der Einstellung durch die ETS dort bekannt sind) aus dem Flash/EEPROM mit ihrer Einstellung versorgt. Das Ergebnis ist dann dass einige KOs aktiv sind (und eine GA haben) und andere KOs eben inaktiv sind (und keine zugewiesene GA haben).
Genau so ist auch KONNEKTING Implementiert.

Bzgl. BCU SDK siehe auch hier: https://www.auto.tuwien.ac.at/~mkoeg...dex.php/bcudoc

Ggf. ließe sich das Memory-Layout optimieren und die Tabellen auf die rein aktiven KOs einkürzen. Aber das würde nur einen Teil des RAMs sparen. Die restliche Datenstruktur so runterzubrechen dass nur noch aktive KOs im RAM gehalten werden ist nochmals mehr Arbeit und nochmal ein größerer Umbau.

Ich zweifle noch daran dass man für dieses vorhaben tatsächlich so viele KOs braucht. Bei 6 Eingängen und 7 Ausgängen müsste man es theoretisch mit einer anderen, ggf. einfacheren Umbaumaßnahme mit 13 KOs auskommen.

Die Anzahl Parameter... stimmt, 256 ist hier zu klein gefasst. Theoretisch sind es beliebig viele, da wir hier keine ID brauchen und der Speicher das Limit vorgibt. Muss das in der Doku nochmals überarbeiten.

[henfri]

Ja, ist auch nix für mich.
Finde es trotzdem spannend.

Gruß,
Hendrik

[mumpf]

Aktuell ist es so, dass KONNEKTING Arduino seitig darauf ausgelegt ist, dass "bekannt" ist was das Gerät für KOs hat.

Ok, ich glaube, ich habe jetzt verstanden, was Du meinst. Man legt schon im Sketch den DPT für ein KO fest, und nicht erst durch die Parameter der Suite. Das hatte ich anders erwartet.

Alle mir bekannten KNX Geräte (offizieller Natur) kennen intern alle ihre KOs und bekommen über die ETS nur noch deren Einstellung.

Ich kenne zumindest ein Gegenbeispiel (zumindest vermute ich das): Das MDT Logikmodul. Die haben 254 KO, aber wenn man in der knxprod nachschaut, gibt es zig Referenzen (ComObjectRef) auf diese KO, die alle möglichen Eigenschaften überschreiben (DPT, ObjectSize, Text, FunctionText).
Wenn man sich z.B. das KO 9 anschaut, dann ist das im Original mit ObjectSize="4 Byte" und ohne DPT definiert. Über ComObjectRef wird das Original-KO mehrfach referenziert, dann mit DPT=1.001 und ObjectSize="1 Bit" oder DPT=5.001 und ObjectSize="1 Byte" etc. redefiniert. Somit kennt die Applikation sicherlich das KO 9 und es werden sicherlich 4 Byte dafür reserviert, aber zur Parametrierung über die ETS gehört sicherlich auch die im konkreten Fall genutze ObjectSize und deren DPT.

Aber ich will Dich gar nicht weiter mit meinen Ideen behelligen, es ist vollkommen OK, dass ich nicht in die Zielgruppe passe. Deswegen habe ich auch angefragt. Besser vorher ein NEIN bekommen als etwas anprogrammieren und dann feststellen, dass nicht geht und auch nicht gehen wird. Ich werde wie gesagt mal schauen, wie weit ich mit dem anderen Projekt komme.

Gruß, Waldemar

[thesing]

Bei meiner Implementation muss aktuell (die maximale) Anzahl der KOs und die jeweilige Größe festgelegt werden. Die Größe der einzelnen KOs könnte man wahrscheinlich auch erst durch die Parametrisierung durch die ETS festlegen, aber aktuell geht es nicht. Die Parameter sind auf Geräteseite einfach Bytearray. Was da drin steht wird durch die knxprod-Datei festgelegt. Da kann man also diverse Parameter überlagern wie man mag. Das CreateKnxProd-Programm kann das allerdings nicht. Man muss das also manuell in der knxprod-Datei konfigurieren.